My biggest gripe with Zed right now (it seems they had changed the default force-formatting of source code) is that it is non-extensible.
I just wanted a custom action when I right click on a file (or multiple files) in the file tree - uh-oh, sorry, you can't have that.
Basically all text editors should be extensible. Emacs and vim, Notepad++ or Sublime - this is one of their core features. Do I need to explain this to the HN crowd?
GPU acceleration is nice, and in general, the whole basic editing experience is quite nice. But lack of extensibility is just a punch below the belt.
There’s tons of extensions for Zed, but you’re asking for particular extension hooks that don’t exist yet.
I expect the reason they don’t is that Zed sandboxes extensions quite aggressively (they’re essentially WASM running under wasmtime), which is fantastic for both security and performance, and it means they don’t break when the app updates, but it also means that a bit more care needs to be put into designing extension points.
No plugins? Those are what give NP++ its real power and usability - for example I use the XML and JSON pretty print functionality daily (on Windows, on my work machine).
I have to agree the keyboard layout is a noticeable bummer. The only actually impactful one I can find on this laptop on my side for now. So, props to the team still!
Having strong SETI@Home vibes from 25 years ago, except of course, this is not for the greater good of humanity, but a for-profit project.
Problem is, from a technical point of view, what kind of made sense back then (most people running desktops, fans always on, energy saving minimal) is kind of stupid today (even if your laptop has no fan, would you want it to be always generating heat?)...
I definitely want my laptops to be cool, quiet and idle most of the time.
I some times play about with local models via ollama/comfyui and more recently ace-step to generate music.
This is short bursts of heat 5-10 m during the render I would not be happy with that for multiple hours a day. I am sure that would have a negative effect on battery health.
Exactly my conclusion, unfortunately I'm too old to pivot now, but anyone in their junior-to-mid days as a software developer should consider this pivot.
And this is only about generating source code in a closed environment. All hell will break loose when Openclaw et al get in the hands of average users...
I wouldn't. Until companies become liable for their security failures, and that liability comes with a big price tag, there will be no money in security. Currently, poor security costs companies nothing, so they won't pay to improve their security.
I tried reading Proust's In Search Of Lost Time some time ago, in which the first 10-20 pages are about a guy lying in his bed at night and observing his own thoughts (roughly). And I quickly realised how I was reading the words and even sentences, but couldn't grasp the meaning of them - I couldn't produce a "mental model" or image of what it was about. It was a very humbling experience.
I used to be an avid reader as a child, even as a teenager. That was a long time ago. I'm looking forward to that time when I will have the mental capacity to read long prose again.
To me, the odd part is when you compare the performance of RPC vs inline code. You present it as if you found something new and foundational, only possible thanks to AI, when in fact, it has nothing to do with AI, and the results should be no surprise to anyone.
Your original architecture was a kludge to start with, it was a self-inflicted wound. This is probably the craziest part:
> We’d tried a few things over the years - optimizing expressions, output caching, and even embedding V8 directly into Go (to avoid the network hop).
I know hindsight is 20/20 - but still, you made the wrong decision at the start, and then you kept digging the hole deeper and deeper. Hopefully a good lesson for everyone working with microservices.
To end on a more positive note, I think this (porting code to other languages/platforms) is one use-case where AI code generation really shines, and will be of immense value in the future. Great reporting, just let's not confuse code generation with architectural decisions.
Oh, I don't disagree. The original vision and what the product ended up doing are light years apart. Likely, had we known what it would evolve into, we would have decided on a different solution (perhaps not JSONata at all, for example).
Having said that, My opinion still is that the previous solution had valid business merit. Though inefficient, the fact that it was infinitely scalable and the only limit was pure dollar cost is pretty valuable. It enables business stakeholders / managers to objectively quantify the value of the feature (for X dollars we get Y business, scaling linearly). I've worked in many systems where this was not at all the case, and there was a hard-limit at some point where the feature simply shut down.
I just wanted a custom action when I right click on a file (or multiple files) in the file tree - uh-oh, sorry, you can't have that.
Basically all text editors should be extensible. Emacs and vim, Notepad++ or Sublime - this is one of their core features. Do I need to explain this to the HN crowd?
GPU acceleration is nice, and in general, the whole basic editing experience is quite nice. But lack of extensibility is just a punch below the belt.
Maybe Zed 2.0 will be worth another look.
reply