I really like all the blog posts and videos the Zed team has put out, thank you if you’re reading this!
Unrelated to this specific post I’m such a fan of Zed. It’s the first feature complete text editor in recent memory that I’ve truly enjoyed using (i.e. it stays out of the way, is really fast, feels well engineered). I’m coming to Zed after years of Emacs which I still have love for but no longer feels like a competitive piece of software (it does not take full advantage of how good computers are today, e.g. gpu rendering or multicore). I really hope Zed stays a fast and lightweight text editor instead of becoming some bloated growth-at-all-cost VC ware (not that they’ve exhibited any signs of that happening). I’d also happily pay for Zed without a subscription based thing for access to LLM features (which I do not use).
> it does not take full advantage of how good computers are today, e.g. gpu rendering or multicore
Why does Emacs need that though? I hear people say this all the time and I don't get it. Multicore kind of works against the structure that Emacs touts as a feature. And GPU rendering? In many applications, I totally agree with these complaints. But it's a text editor.
I tried Zed myself, and it's good. But it doesn't dethrone Emacs (for me personally).
Long time emacs user here (+20 years, yikes). I've used it on all kinds of computers during this time. Even a relatively modest computer from 2024 is an absolute beast compared to something from the year 2000.
With that said, there are text editing operations that can cause it to grind to a complete halt, especially working with large files (or very long lines). And it shouldn't, you know? I think emacs users sort of internalize which operations they should avoid. It's kind of ridiculous to have to do that in a text editor with the massive amounts of compute that our computers have today.
** Emacs is now capable of editing files with very long lines.
The display of long lines has been optimized, and Emacs should no
longer choke when a buffer on display contains long lines. The
variable 'long-line-threshold' controls whether and when these display
optimizations are in effect.
A companion variable 'large-hscroll-threshold' controls when another
set of display optimizations are in effect, which are aimed
specifically at speeding up display of long lines that are truncated
on display.
> Multicore kind of works against the structure that Emacs touts as a feature.
I have consistent issues with emacs locking up when executing network requests. I'm sure there's a specific bug that could be hunted down and addressed, but this sort of thing shouldn't happen much in an editor that's multicore by default.
I'm not trying to dismiss emacs' reasoning, of course, but I can understand being disgruntled with it.
The actual rendering I've been quite please by, though!
Yeah this is one reason, or Emacs freezing for up to a minute when updating packages. Also when using an LSP I notice latency.
I use Emacs GUI (outside of the terminal) and comparing performance for rending to something like Zed or Sublime is definitely noticeable. It’s great that Emacs is so resource efficient but sometimes I wish it used more of my beefy computer(s).
Like I said I still love Emacs and it’s okay for it to make a different set of trade-offs. I honestly didn’t think I’d ever switch editors but here we are!
Removing the interpreter lock for a few specialized tasks (without sweeping runtime changes to Emacs) would be enough to fix most of these issues -- parsing JSON from process output into lisp data in a background thread is one candidate. [1]
Installing packages does not need to block either, there is no architectural limitation here. The Elpaca package manager for Emacs provides async, parallel package updates. Loading packages into the Lisp image will block though, there's no way around that.
The other big source of input lag is garbage collection, and there are some ongoing efforts to use the MPS library in Emacs for a copying, concurrent GC. This is a big change and I don't know if this experiment will go anywhere, but Eli Zaretskii and co are trying.
That's fair I guess. In the case of IO that can be an issue. When I hear multicore, I assume we're talking about parallelism, not concurrency.
As for LSP, other than the Nim langserver, I've been quite satisfied with Eglot's performance. I'm curious what your setup is like. To be fair, I'm running a highly customized Doom Emacs config, so it's possible I inherited some non-vanilla optimizations I'm not aware of.
GPU rendering simplifies smooth text scrolling which used to be a thing on some dumb terminals and microcomputers like Amiga that supported it in hardware. Most emulators are locking character cells on a fixed grid and we miss out on such niceties.
I’ve refused to rent in a place that required a brokers fee, and that meant most decent apartments were not available to me. I for one am glad this is finally coming to an end (after the first failed attempt).
Rental brokers are useless, and their fees often exceed 1 month rent (15% of annual rent, so $5k/mo apartment you’re paying first month $5k, deposit $5k, and $9k brokers fee).
One of the biggest goals of the component model is that it doesn't matter what language your component is written in. Composition can happen anytime one component exports an interface and another component imports it. https://component-model.bytecodealliance.org/creating-and-co...
WASM is basically similar to JVM bytecode. So the comparison would be like using compiled code from Java, Scala and/or Kotlin for example.
The source language only determines how the code is expressed in WASM and whether or not it also needs to bundle / compile-in some runtime code baggage for it to work.
I develop the Scala-to-Wasm compiler, and also maintain the JVM backend of Scala. I can tell you that Wasm is very different from JVM bytecode.
The fundamental difference is that the JVM bytecode has an object model. When they talk to each other, Java, Scala and Kotlin do so at the abstraction level of the JVM object model. You can directly call methods between them because virtual dispatch of methods is a concept with semantics in the bytecode.
There's no such thing in Wasm, even with the GC extension. You get structs and arrays, but nothing like methods. If you want virtual dispatch, you encode it yourself using your own design of virtual method tables. That means Java, Scala and Kotlin, despite all having their Wasm GC backend at this point, cannot call each other's methods in Wasm.
Yes, in retrospect I should have mentioned "Components" in my comment and just compared it to "Java" in general instead. I felt that was implied due to the thread and topic of discussion.
From a pragmatic end-user point-of-view explanation, I would still stand by saying WASM Component Model may be similar to working within the JVM multi-language ecosystem. One can work with code compiled from multiple different languages, but the generated code may be different because of the different compilers.
I am confused. You are referring to wasm modules here? And Component Model / WASI / WIT will give us polyglot interface-based programming then, right? Call each other's methods through the WIT interface between components.
Even the component model has nothing to say about the concept of methods. All you have are top-level functions with immutable arguments and immutable results. You can't hold on to an instance of an object created by the other language. You could hold an integer handle, but then you don't get garbage collection across the two languages.
So no, we're still a long way from the abstractions of a JVM, even taking the component model into account.
It's a good step in the direction of better interoperability between languages, though, don't get me wrong.
For the audience that would be looking to use the WASM Component Model, and not be an infrastructure implementer of it, whether or not they meet some definition of a method, the component model does define things called resources [1] that have "methods". You'll hold a "handle" to it like you would in your own programming language with the expected drop and/or GC semantics (once implemented [2]) because code is generated to access it like any other FFI like C/C++.
With that in mind, the other confusing thing one may come across is composition vs linking within your WASM runtime that supports the Component Model. When you hear "composition" think of compile-time merging of libraries such that the bundle may have less unresolved dependencies of WASM code/implemented component interfaces. Anything unresolved needs to be linked at runtime with your WASM runtime of choice, like wasmtime [3]. Pretty interesting reading/potential after reading if you ask me -- sounds like you could implement something like a custom Java classloader hierarchy [4].
But I'd agree with a statement saying it is still a long way for general usage.
The vaccine is effective for several decades, and hep b can spread through bodily fluids not just needles. Exposure to another kid with hep b could spread to your brothers kid.
From what I've seen on social media from the soft anti vax crowd, pediatricians nowadays are pushing for a lot more vaccines compared to their parents' time. There is a reason for each individual vaccine, sure, but the difference is huge and something to be wary of.
Problem is the risk vs reward question seems to be ignored in favor of talking about just the reward part. I'm sure there are reasons for not talking about the risk part like you don't want to be too chummy with the anti vax crowd or you don't want to discourage vaccine use but it makes most people's bs detector go off. There is never reward without risk.
AFAIK it’s not spread through saliva, or maybe the probability of spread is just much lower? But yes, sloppy kisses from adult relatives are gross and spread other things like herpes.
This is a neat idea (and good looking product), but unfortunately the issue is the people who tend to interrupt you in the office ignore all explicit signals in my experience. Wearing noise cancelling headphones is an accepted sign of “in the flow, pls don’t interrupt” yet some folks feel like it doesn’t apply to them. Or they’d just stand next to your desk waiting for your attention. I’m pretty jaded (and probably still recovering from burnout) but these types of people made work unbearable. Usually an executive walking up to ask for the status of something even though there are other ways they can look at the status of something (JIRA, standup, slack updates).
I don't want to disagree with your general statement, because it's correct, but I would like to point out that wearing noise cancelling headphones is not a good signal of ``in the flow, pls don’t interrupt.'' The only thing it's a good signal of is ``I'm listening to something.''
Some people wear headphones simply because they want to listen to music or a podcast while they send/check email. Some people only put them on when they're in a meeting. And yes, some people wear them because they want to be left alone.
There are as many reasons to wear noise cancelling headphones as there are people wearing noise cancelling headphones, and assuming that everyone around you should know what it means to you is as insane as walking up to someone wearing noise cancelling headphones and asking for an update.
> Wearing noise cancelling headphones is an accepted sign of “in the flow, pls don’t interrupt”
Well, someone could always say, sorry I thought those were just regular headphones. :)
Anyway, my philosophy is that I'm being paid by my employer not only to do work, but to help others do their job as well. I WANT to be the person that my co-workers are comfortable walking up to and asking questions even if I am in the middle of something. (Because I'm ALWAYS in the middle of something anyway.) It doesn't take many interactions like this before they start to associate you with the word "indispensable." Which is a good for job security and peer testimonials. And of course making friends.
The general issue with people that don't care is, well, they don't care. The problem with being a reasonable person (or at least being the reasonable person in a certain situation) is that reason stops if the other party is not playing. It rarely helps to keep throwing subtle hints at somebody who just isn't going to cooperate or respect boundaries. It's the juggernaut in human relationships, especially when there's a power imbalance or differing incentives.
I don't think you have the right to tell your coworkers to leave you alone. Part of working means collaboration and if you're unwilling to do that, you don't belong on a team. You're not doing brain surgery that will permanently alter the life of some helpless patient. you're not meticulously stacking the last card on top of a 10 ft house of cards exhibit where tens of hours of work will be completely lost if your concentration strays to show your face to another human being and utter a few words.
You absolutely do. Many coworkers will bug you to ask instead of doing their own research, bug you to chitchat, etc.
They can always book time with you, send an email/IM, etc if there's something they can't resolve on their own.
You have your own deliverables and being interrupted every 10 minutes with inane questions that a web search or a look at the internal wiki/KB would have resolved is not a productive use of anyone's time.
Also, forcing them to wait produces better quality, better researched questions as hopefully they should make some attempt to resolve things on their own.
You had to ask people things when you learned. It's not different now that you're the one with the knowledge. And sometimes people not using the docs means your documentation sucks or needs updating
The problem isn’t people or colleagues asking for help, the problem is feeling entitled to your time exactly when they want it. No one would get any work done if no one had schedules and respected meetings at pre-arranged times.
Also, no one I collaborated with or on my team was ever the issue (except that one time at my first job when someone lied their way into a role, and constantly asked me to do their job). If my team member ever wanted to chat or distract me I had no issue.
It’s the fucking CEO who hasn’t bothered to talk to you for a month and ignore every email walking up to your desk, literally knocking on your table to get you to take your headphones off and give them your attention and saying “hey, when is this new feature gonna be done” when the project management software shows very clearly that everything is on track to ship at X date.
Really this isn’t about collaboration, it’s about people being entitled.
It's about politeness. If somebody took care to produce a sign asking to avoid interruptions, I will think twice whether my inquiry is both urgent and important. If it is not, I will postpone it. If it is, I'll beg for pardon but interrupt.
But no, a context switch required for uttering a few words can absolutely topple the tower of concentration somebody has spent last half an hour building. Certain occupations, engineering among them, require ingesting a large amount of context and making sense of it before productive work can start. My lack of patience with a question which I could answer with 10 minutes of research (or asking someone else) may cost my colleague an hour of lost productivity. Being mindful of this helps everyone, including yourself when the roles are swapped.
I hope you're not a manager, because this is horrible guidance. For starters, there are some neurodivergent people who really get thrown off by interruptions, especially if they are really focused on the task at hand. It is entirely unreasonable for you to expect that your coworkers should be available at your beck and call. And you are totally ignoring the fact the countless studies showing that workplace interruptions cost companies money.
If a worker needs disability accommodations they can get them from management. We're not all going to walk on eggshells because someone might be neurodivergent. If they are present in the office they are part of a team and that requires interaction.
Walk on eggshells? Schedule a designated time to talk. It's not that difficult. Are you that disorganized that you need to share your thoughts the second they occur to you? Even for neurotypicals, it takes some time to refocus after interruption. Your approach has been proven to lower productivity and its costs companies serious money.
Displaying a "Busy" signal is a way of implementing "No.". Another part of personal skills is learning when to not interrupt. Implementing an unambiguous signal can help. Learning to not ignore the signal helps. As long as the signal isn't abused or isn't "always on".
That would require them to be interrupted, which would subsequently require them to refocus. Your time is not more important than your coworker's time.
Each interruption is a drain on productivity, which costs the company money. What part about this do you not understand?
It's not a lack of understanding, it's a difference in belief. I believe you are self-aggrandizing by pretending that you're some rain man whose superhuman skills, not found anywhere else or under any conditions other than pretentious "focus mode" - will evaporate if you're forced to be held to standard of common decency. Sorry dude, nothing you work on is that important.
Your belief is based on a misunderstanding. If you have not worked in a context where holding large amounts of details and their relationships in your head does not lead to "losing the picture" when interrupted, you have had a luxury not everyone gets to experience.
Getting "into the flow", or loading/reloading the details into your head typically takes 15 to 30 minutes for sufficiently intricate task or dataset. In such a context, a mere, "Hey, you got a minute?" is costly — more so, if i happens repeatedly during the day.
The importance of my work is determined by the people paying me, not some dipshit on hacker news. And fortunately they value my time enough to allow for deep work hours. It's not that difficult.
Allowing for constant interruptions under the guise of "collaboration" costs companies money. If you're in a management situation, you should know that your attitude will lead to waste.
All of this entirely depends on your company culture. And for every choice you make (conscious or not) there are consequences.
Perhaps the culture within the company / department / team is to allow interruptions in the name of "collaboration". Hopefully the increased value gained by "collaborating" that way is worth the cost. Some of that cost is time (productivity), some is people literally quitting. Eventually you're left with a company full of people who don't mind being interrupted and I would assume are interrupters themselves, and I'd assume this effect is exponential, causing lower and lower productivity.
As a manager, you can't have this culture and then also complain about the lack of productivity, missed estimates, etc. (Well, you can, but that in turn will increase stress levels and unhappiness and cause more people to quit.)
Your competitor who sees collaboration is possible with planning, proper async communication channels, and some specific culture choices will have a nicer environment and happily hire away your most talented and knowledgeable people.
> where tens of hours of work will be completely lost if your concentration strays to show your face to another human being and utter a few words.
After being interrupted, it takes on average over 23 minutes [1] to get back on track. The average time lost is almost 3 hours per day, or 60 hours per month [2].
> You're not meticulously stacking the last card on top of a 10 ft house of cards exhibit where tens of hours of work will be completely lost if your concentration strays to show your face to another human being and utter a few words.
You have no idea.
Thank god we have this WFH thing now. I can build this house of cards without anyone interrupting me saying I'm not building a house of cards.
But really, as a software engineer you should not be building a house of cards, right? Surely you should not boldly insist that you never be subjected to collaboration from other members of your team because you are intent on building a system that is in constant danger of collapse.
In my experience, the house of cards is usually debugging, not building. I've had to do some pretty crazy debugging, stepping through deep call stacks frame by frame, keeping track of big data structures as they change along the way. This can take a huge amount of focus that would absolutely be ruined by even a 5 second conversation.
I fully accept that programming is purely a mental task. I choose to think with others and then code in my own time. The tasks are now so short that there is literally no space for someone to interrupt.
I don't think the suggestion is to "never" be subjected to collaboration, but certainly there should be a balance between collaboration and deep work that shouldn't be interrupted if possible.
It depends on the office culture. The last time I worked in an office, I used a red/green busy signal like this, and people would generally respect it.
It really does depend on office culture. Some people might be more reasonable if you communicate directly. I don't think it would go down well everywhere if you state "Hey! No talking to me if Mr. Smurf is on the table!"... Mr Smurf might have an unfortunate accident sooner rather than later.
Also, what else are standups even for? Everything I've read or seen IRL is some bullshit about using them for teams to "align" or "sync up" or "share progress" or nine other euphemisms for status updates. Let's call a spade a spade.
Oh. Sounds like you're referring to Agile and Standup with capital letters. In my experience people talk about agile-with-a-capital-A and standup-with-a-capital-S and those two don't really match what actually happens in the real world, at least in my experience.
No, the plan is to build a simple general purpose language. Lots of folks already enjoy using Zig, and not every language has to be in direct competition with others.
The Little Schemer and The Seasoned Schemer are both beginner books using Scheme. The Reasoned Schemer uses Scheme + Minikanren, an extension of Scheme that allows for logical/relational programming (look up Prolog and Datalog as languages in the same vein). The Little Typer is the linked book covering type systems and, specifically, dependent typing. The Little Learner covers machine learning. The Little Prover uses the same format and has you develop proofs.
Little, Seasoned, and Reasoned are, IMO, the better books in the series to start with. I found the later ones to be good but very dense and not always as clear, had to step back a lot more and reread sections. That's mostly due to the material being much harder and more technical than the earlier books, not a quality issue with the writing itself.
My recommend reading order for someone with no Racket, Scheme, or Lisp experience wanting to tackle the series would be: Little -> Seasoned -> [Optional: Reasoned] -> {Any order: Prover, Typer, Learner}. I think Prover may be better before Typer, but it's been a while since I looked at either, so a soft recommendation of Prover -> Typer.
If you have some Racket, Scheme, or Lisp experience, I'd suggest to either skim the first couple books to get used to the format or skip them entirely and use Reasoned as your first book in the series.
With no Scheme or programming background, I'd study HtDP (https://htdp.org) as an interlude, after The Little Schemer. Pace is gentle, and explanations about program design are long and very lucid. After those two, I'd try The Little MLer. The other books are quite advanced, better to build solid foundations first.
The Little Schemer is one of my top two favorite programming books. But it's not something I'd recommend as a way to learn how to do the programmer job. It's fun and useful in the way that dropping acid is fun and useful, at least from what I've been told as a teetotaler who's never tried anything stronger than Tylenol. When I read that book, it has a long-lasting aftereffect on how I approach problem solving and maybe the world in general.
I have non-data-driven (but informed) opinions on how to pick up coding as a new skill. I think it helps to find a hobby space you're interested in that will motivate you to push through when you get stuck on something. There are some great platforms for live-tinkering with electronics, CircuitPython for example. Or web stuff, if there's a way to get into it in 2024 without being overwhelmed by frameworks and complexity.
Friedman's books are all great. All of them. But they don't work for everybody.
If you can be relaxed and think of the interaction as play, they're very good. If you're feeling more of a "serious business" mindset, it can be hard to get in the groove of his style.
There are a lot of jokes about food and encouragement to take breaks. If you can get into the learning as play mindset, I'd strongly encourage taking the recommended breaks. maybe grab a snack, but spend some time noodling around with the ideas in each section. I think that's the real point, food is a good excuse to pause and get your hands off the keyboard.
Racket should be easy to install. Big download button for a ton of platforms here - https://racket-lang.org
I believe HN still runs on the racket runtime. it may appear to be a toy, but thoughtful design can take you a long long way. it's well supported and a great way to get started.
The other classic is the wizard book - https://sarabander.github.io/sicp/html/index.xhtml the structure and interpretation of computer programs. This'll walk you up to and somewhat through compilation.
There are a ton of programming languages all with amazing assortments of features.
Scheme is much more "there's nothing left to take away". I think it's very much the undisputed champion in that regard. While still being able to ship software. Scheme may not be the optimal choice for all people in all situations (obviously). It's a spectacular place to start though. It may not turn out to be the language for you. That's totally fine! But it'll get you deep enough to figure out what you like and don't like. And, when it comes down to it, you can shape it into pretty much anything.
So, what's the recommended Scheme implementation to "get things done", and not only for learning CS stuffs?
For example, now our backend system is mostly implemented in Go (some with Fiber, some with Echo). The rest are pretty common: Postgres, Mongo, Firebase etc.
Perhaps Gambit? BTW, I have nothing against experimentation. Not everything have to do with practical purpose on mind. That's why I'm also tinkering with Haskell & Ocaml :D
Racket, Guile, Gambit, Chicken Scheme, chez are all pretty solid with different trade-offs. I think Racket has a fairly decent developer experience and others like chez and gambit are great implementations but may be lacking in tooling (in the sense that you won’t get a nice package manager or build tool). Options exist (like Akku) but IMO the scheme ecosystem is somewhat disjointed.
Guile integrates well with C, and uses the same build tools as a lot of the GNU ecosystem (make and autotools).
I recognize the answer isn’t maybe the most helpful but it does exemplify, in my opinion, one of the challenges with using Scheme for getting things done.
If I had to put scheme in production, I think I'd pick racket. I think that would give me the best chance at helping other dev's get set up, explain the problem, and show the solution. anta40 asked about packages, and racket has the db interaction as part of the normal distribution, I see there's a mongo client in the package manager, but no idea about firebase. I guess wrap the cli?
Racket has been ported over to the chez backend, and got a big performance pop. And they've done stuff with arrays instead of lists, immutable lists. Pointer chasing is always going to have certain tradeoffs.
As much as I love scheme, it's going to be a fringe language. Small shop, that can be ok. You need to hire 50 people? yeah, that's not really going to work out I think.
anta40 also mentiond stuff like Haskell and Ocaml. I feel like those are much easier to refactor, the compiler helps so much, you just chase errors and feel good about code staying correct. scheme, I feel like I just throw it away and start over.
For personal stuff, language doesn't matter, think harder, you'll find a way out.
For "team" stuff. Ugh. That really depends on how dysfunctional the team is. I think go is a pretty solid default. But everything is very textured and nuanced. Just you? go with what you know. Wasting time ramping up on a shiny new thing won't ship. You have a mostly working team? Keep doing that. add linters or whatever to improve code quality.
Screwing around with a weekend project that might turn into something big? Racket seems like the path of least resistance. it's a hard question to answer optimally.
I see... so Racket is the most likely choice for work.
Obviously won't use it for my office though, considering Scheme devs here are practically... zero.
Or probably I'll just use Scheme for learning compiler dev :) :D
IMHO, it's a lot easier to write compilers in Haskell or ocaml, for a bunch of reasons.
you might take a look at https://wespiser.com/writings/wyas/00_overview.html
which walks through writing a scheme implementation in Haskell.
Do what's fun. I think both of those are worth poking at.
Maybe Gauche (https://practical-scheme.net/gauche/)? It kinda depends on what you want to get done, though. If the thing you want to get done is to make an operating system I guess Loko would be your go-to.
EDIT: There's also GNU Kawa, which runs on the JVM, so you get all of that Java-y goodness in a language that's actually nice to use.
Unrelated to this specific post I’m such a fan of Zed. It’s the first feature complete text editor in recent memory that I’ve truly enjoyed using (i.e. it stays out of the way, is really fast, feels well engineered). I’m coming to Zed after years of Emacs which I still have love for but no longer feels like a competitive piece of software (it does not take full advantage of how good computers are today, e.g. gpu rendering or multicore). I really hope Zed stays a fast and lightweight text editor instead of becoming some bloated growth-at-all-cost VC ware (not that they’ve exhibited any signs of that happening). I’d also happily pay for Zed without a subscription based thing for access to LLM features (which I do not use).