Not the OP, but for me ST can't be beat in terms of how easy it is to write a plugin. It uses Python (Zed is Rust). Plugins generally auto-reloads. If extensibility is important to you, ST is still the way to go.
1. Implying that there are only "a few islands left" shoes a strong bias towards assuming that only thins humans do in the digital realm is relevant, when in fact, the vast majority of things humans do are not in the digital sphere at all.
2. It's pretty clear when most people say that machine intelligence is close, right now, they are alluding to LLM or Deep Learning based approaches. I don't think you should assume they mean machines will catch up in a 100 years. They seem to imply it will be by 2030 or sowmthing.
I think there is a programming language hole for a Rust-like language, but with GC and green threads. One that dispenses with single-ownership, and async/await footguns.
Something like F#/Kotlin is closest in terms of developer experience.
Unfortunately, we are really lacking a language that skews badly on some other axis
- F# - tainted by being Windows only for really long and being Microsoft.
- Kotlin - tainted by the JVM
- Java 24+ - has virtual threads, sum types, match expressions and other niceties, but tainted by the JVM again (Verbosity included, but this is not really a factor with IDEs and LLMs.)
Note that the opinions above are not mine, but "consensus". I'd say they are all unfair opinions.
I feel like people end up favoring new languages, simply because of novelty. Like, inevitably, somebody is gonna say Gleam. I'm all for having existing BEAM users getting access to new languages, but I'm not sure why one would pick a BEAM language for non-server applications when the developer tooling story for CLI apps, line-of-business apps and so on is so much stronger for the .NET and JVM ecosystems. No offense to the Gleam folks intended.
Aider has an ide mode close to this. Check out https://nikhilism.com/post/2026/nudge-skill/ to add similar behavior to certain agents. I too, am waiting for IDEs to do this in a polished way. next tab edit is not quite it
What money do you think pays for most of the development of the Linux kernel? I assure you, it is not the altruistic goodwill of people around the world.
> The plain truth is that developers expect to get their tools free of charge.
This is an accurate, but damning indictment of how some of the most highly paid workers on the planet won't pay for tools. Unlike nearly every other profession.
Folks, if you can afford it, please pay for quality software, instead of relying on FAANG and VC money to keep the tools going!
> But at present, there is a big gap in the workflow: You leave your editor, open a browser, navigate to some page or tab, then navigate to the exact same place in the code you were just looking at, click on a line to open a text box, and finally you can write your comment.
After reading Careless People, I would be more surprised if Meta was _not_ doing these things. The company is amoral/immoral in the truest "responsibility to shareholders" (number go up) way. It needs to be made to lose everything.
I’m confused about the assertion that green threads perform badly. 3 of the top platforms for high concurrency servers use or plan to use green threads (Go, Erlang, Java). My understanding was that green threads have limitations with C FFI which is why lower level languages don’t use them (Rust). Rust may also have performance concerns since it has other constraints to deal with.