On the topic of Zed itself as a VSCode replacement - my experience is mixed. I loved it at first, but with time the papercuts add up. The responsiveness difference isn't that big on my system, but Zed's memory usage (with the TS language server in particular) is scandalous. As far as DX goes it's probably at 85% of the level VSCode provides, but in this space QoL features matter a lot. Oh, and it still can't render emojis in buffers on Linux...
I actually find Zed pretty reasonable in terms of memory usage. But yeah, like you say, there are lots of small UX/DX papercuts that are just unfortunate. In some cases I'm not sure it's even Zed's fault, it's just years and years of expecting things to work a certain way because of VS Code and they work differently in Zed.
Eg: Ctrl+P "Open Fol.." in Zed does not surface "Opening a Folder". Zed doesn't call them folders. You have to know that's called "Workspace". And even then, if you type "Open Work..." it doesn't surface! You have to purposefully start with "work..."
I don't think it's conscious or even a result of not caring about UX/DX. But I do think you're right - I've noticed the loudest voices in their Issue queue are people wanting things like better vim support, helix keybind support (super niche terminal modal editor), etc. Fine if they want to make that their niche but if you are migrating from VS Code like 99% of people you can't have these kinds of papercuts, people will just uninstall.
I've been attempting to use Zed as a VSCode replacement but between the lack of bitmap font support (Criminal in an alleged code editor), and the weird UI choices, it's been hard. I want to love it, but what is "performance" if I have to spend more time working around the UI and lack of features from extensions. Strangest issue I've encountered is the colours being completely wrong when using Wayland.. colours are perfect when ran with Xwayland. I'll give it a plus though for native transparency for the background. Much nicer than having to make the entire window transparent, including the foreground text like with VSCode.
Terminus. I personally love it. There's a TTF version called Terminess that includes the original bitmaps for certain sizes, and uses the more blurry style font for sizes the original didn't have. You can use it with certain programs like VSCode that don't allow you to select bitmap fonts, yet actually support them.
I agree. One of the strangest things I found was “in-built” support for a things like TailwindCSS. The LSP starts showing warning in all HTML/TSX files and confuses me to no end. I know, I can turn it off with the setting, but the choice seems so confusing. Tailwind is just one of the thousands of CSS libraries. Why enable it without any mention in the codebase.
I have actually ditched PyCharm for the snappiness of Zed. But the paper cuts are really adding up.
The point about papercuts adding up so resonates with me! I loved Zed initially and did find it more responsive than VS Code, loved the Zed Agent autocomplete, etc. However, I eventually and reluctantly went back to VS Code. The papercut that finally did it for me was [this open bug](https://github.com/zed-industries/zed/issues/36516) because of which I was not able to step into a packaged library's code when I was debugging my own code, this was in Python.
my favorite is Ctrl+Shift+A which lets you search through all available UI actions (hence the A). That's just so helpful if you know the IDE can do something but you forgot where in the menu structure it was. And to top things off, you can also use Ctrl+Shift+A to look up the keyboard shortcuts for every possible action
I have 4-5 typescript projects and one python opened in Zed at any given time (with a bunch of LSPs, ACPs, opened terminals, etc.) and I see around 1.2 - 1.4gb usage.
I opened just one of the typescript projects inside VSCode and I see something like 1gb (combining the helpers usage). I'm not using it actively, so no extra plugins and so on.
That's on mac, so I guess it may vary on other systems.
I think there’s a bug? It used to be memory efficient and now I periodically notice it explodes. Quit and restart fixes it
I don’t have any extensions installed and I’m basically leaving it open, idle, as a note scratch space. I do have projects open with many files but not many actual files are open
> after using it for months you get a ‘feel’ for what kind of mistakes it makes
Sure, go ahead and bet your entire operation on your intuition of how a non-deterministic, constantly changing black box of software "behaves". Don't see how that could backfire.
not betting my entire operation - if the only thing stopping a bad 'deploy' command destroying your entire operation is that you don't trust the agent to run it, then you have worse problems than too much trust in agents.
I similarly use my 'intuition' (i.e. evidence-based previous experiences) to decide what people in my team can have access to what services.
I'm not saying intuition has no place in decision making, but I do take issue with saying it applies equally to human colleagues and autonomous agents. It would be just as unreliable if people on your team displayed random regressions in their capabilities on a month to month basis.
Reports of people losing data and other resources due to unintended actions from autonomous agents come out practically every week. I don't think it's dishonest to say that could have catastrophic impact on the product/service they're developing.
This seems like another instance of a problem I see so, so often in regard to LLMs: people observe the fact that LLMs are fundamentally nondeterministic, in ways that are not possible to truly predict or learn in any long-term way...and they equate that, mistakenly, to the fact that humans, other software, what have you sometimes make mistakes. In ways that are generally understandable, predictable, and remediable.
Just because I don't know what's in every piece of software I'm running doesn't mean it's all equally unreliable, nor that it's unreliable in the same way that LLM output is.
That's like saying just because the weather forecast sometimes gets it wrong, meteorologists are complete bullshit and there's no use in looking at the forecast at all.
>That's like saying just because the weather forecast sometimes gets it wrong, meteorologists are complete bullshit and there's no use in looking at the forecast at all.
Are you really not seeing that GP is saying exactly this about LLMs?
What you want for this to be practical is verification and low enough error rate. Same as in any human-driven development process.
Yes, they are; through the lens the person above offered that is.
In practice, all we ever get to deal with is empirical/statistical, and the person above was making an argument where they singled out LLMs for being statistical. You may reject me taking an issue with this on principled grounds, because regular programs are just structured logic, but they cease to be just that once you actually run them. Real hardware runs them. Even fully verified, machine-checked, correctly designed/specified software, only interacting with other such software, can enter into an inconsistent state through no fault of its own. Theory stops being theory once you put it in practice. And the utmost majority of programs fail the aforementioned criteria to begin with.
> people observe the fact that LLMs are fundamentally nondeterministic
LLMs are not "non-deterministic", let alone fundamentally so. If I launch a model locally, pin the seed, and ask the exact same question 10x, I'll get the same answer every single time down to the very byte. Provided you select your hardware and inference engine correctly, the output remains reproducible even across different machines. They're not even stateful! You literally send along the entire state (context window) every single time.
Now obviously, you might instead mean a more "practical" version of this, their general semantic unpredictability. But even then, every now and then I do ask the "same" question to LLMs, and they keep giving essentially the "same" response. They're pretty darn semantically stable.
> In ways that are generally understandable, predictable, and remediable.
You could say the same thing about the issue in the OP. You have a very easy to understand issue that behaves super predictably, and will be (imo) remediable just fine by the various service providers.
Now think of all the hard to impossible to reproduce bugs people just end up working around. The never ending list of vulnerabilities and vulnerability categories. The inexplicable errors that arise due to real world hardware issues. Yes, LLMs are statistical in nature, not artisanally hardwired. But in the end, they're operated in the same empirical way, along the same lines of concerns, and with surprisingly similar outcomes and consequences at times.
You're not going to understand the millions (or really, tens or hundreds of millions) of lines of code running on a typical machine. You'll never be able to exhaustively predict their behavior (especially how they interact with terabytes of data or more over time) and the defects contained within. You'll never remediate those defects fully. Hell, even for classes of problems where such a thing would be possible to achieve structurally, people are resisting the change.
If they want to take an issue with LLMs, a plain gesturing at their statistical nature is just not particularly convincing. Not in a categorical, drop the mic way at least, that's for sure.
Sorry, we have not tested on Fedora before release. Did not expect so much interest in the first hours after release...
I have now installed Fedora in a VM (ARM64 architecture, though) and it does load, but cannot identify processes. I'm investigating this now.
The other issue seems to be with eBPF compatibility. That's a moving target and I'll investigate next. But resources are limited, I'll need some time to dig into this.
There's some good feedback in the GitHub issue on the subject, seems to happen on slightly newer versions of the kernel than the one you've tested on and affects other distros like Arch as well. I'll keep an eye on the discussion and test again once updates are ready.
"Note: Little Snitch version 1.0.0 does not currently work with the Btrfs file system! Btrfs is used by default on Fedora, so Little Snitch does not currently identify processes on Fedora. We are working on an 1.0.1 release to fix the issue as soon as possible!"
It crashed my Fedora 43 installation (maxed out CPU and RAM) right after installing from .rpm. After reboot it can't even load plasmashell. I'm typing this after booting into a Fedora 42 backup. 42!
Had the same issue on arch, though survived it OK (6.19.11-zen1-1-zen). Maybe it's a zen kernel thing, it only pegged 2-3 cores and the others were OK so could jump in and kill it.
Yeah, because no third party program has ever crashed on any other OS.
Come on, this is an absurd comment. Linux has its issues, this is not a serious example of what is keeping normal people from using Linux as a desktop OS. Normal people are not installing the first release of a privacy networking tool that requires you to OK connections.
The take on flatpaks is such an uninformed one. DMGs on MacOS come with all the dependencies bundled in, which make them essentially just as big as the comparable flatpak (minus the shared runtime that gets installed once)
Seriously, the amount flatpak misinformation that people hold onto is absolutely wild. Ex: I have had to show people it does differential updates because they don't bother to read the output.
Flatpaks are easily the best gui desktop app experience for users we have today.
That's not the user experience though, the user experience is it says "go to the discover app and install <program>" and they do that and it just works. Downloading a tarball is not the normal way to install stuff on Linux, and given everyone has phones where the standard is "install on the app store", it's hardly some new experience, in fact, it's more natural for normal users.
IMO around December of last year LLM output (for coding at least, not for everything) went from "almost 100% certainly slop" to "probably not slop, if you asked for the right thing while being aware of context limitations".
A lot of people seem stuck with their older (correct at the time) views of them still always producing slop.
FWIW I am more of an AI doomer (in the sense that I think the economic results from them will be disastrous for knowledge workers given our political realities) than booster, but in terms of utility to get work done they did pass a clear inflection point quite recently.
I think LLMs currently need to be used by someone who knows what they are doing to produce value, but the jump they made from being endless slop machines to useful tools in the right hands is enough for me to assume it is only a matter of time until they will be useful tools in the hands of even the untrained masses.
I wish this wasn't true because I think it will economically upend the industry in which I have a career, but sadly the universe doesn't care what I wish.
> assume it is only a matter of time until they will be useful tools in the hands of even the untrained masses.
IMO this vastly overestimates how good the "untrained masses" are at thinking in a logical, mathematical way. Apparently something as basic as Calculus II has a fail rate of ~50% in most universities.
There's nothing "basic" about Calculus II. Calculus is uniquely cursed in mathematical education because everything that comes before it is more or less rooted in intuition about the real world, while calculus is built on axioms that are far more abstract and not substantiated well (not until later in your mathematical education). I expect many intelligent, resourceful people to fail it and I think it says more about the abstractions we're teaching than anything else.
But also, prompting LLMs to give good results is nowhere near as complex as calculus.
If they truly did, there wouldn't be a huge amount of humans whose role is basically "Take what users/executives say they want, and figure out what they REALLY want, then write that down for others".
Maybe I've worked for too many startups, and only consulted for larger companies, but everywhere in businesses I see so many problems that are basically "Others misunderstood what that person meant" and/or "Someone thought they wanted X, they actually wanted Y".
The multi-decade existence of roles like "business analysts" and "product owners" (and sometimes "customer success") is pretty strong evidence that this is not the case.
Most people on here don’t belong to that group of people. So ofc they can find a way to create value out of a thing that requires some tinkering and playing with.
The question is can the techniques evolve to become technologies to produce stuff with minimal effort - whilst only knowing the bare minimum. I’m not convinced personally - it’s a pipe dream and overlooks the innate skill necessary to produce stuff.
> I wish this wasn't true because I think it will economically upend the industry in which I have a career, but sadly the universe doesn't care what I wish.
I mean, yes. I'm worried about my career too, but for different reasons. I don't think these things are actually good enough to replace me, but I do think it doesn't matter to the people signing the cheques.
I don't believe LLMs are producing anything better than slop. I think people's standards have been sinking for a long time and will continue to sink until they reach the level LLMs produce
The problem isn't just LLMs and the fact they produce slop, it's that people are overall pretty fine with slop
I'm not though, so there's no place for me in most software business anymore
But I look at software from the perspective of them as being objects.
Since it’s intangible people can’t see within. So something can look pretty even if underlying it all, it’s slop.
However, there is an implicit trade off - mounting slop makes you more vulnerable from a security standpoint, bugs etc which can destroy trust and experience of using the software. This can essentially put the life of a business at risk.
People aren’t thinking so much about that risk - because it hasn’t happened to anyone large substantially. What I think about is will slop just continue to mount unchecked? Or are people expecting there to be improvements that enable oneself to go back and clean up the slop with more powerful tooling?
If the latter does not come about, I think we will see more firms come under stress.
Overall though, I think too much focus is on the acceleration of output. I never think that’s the most important thing. It’s secondary to having a crystal clear vision. The problem is to have a clear vision requires doing a lot of grunt work - it trains and conditions your mind to think a particular kind of way.
It will be interesting to see how this all plays out.
Based on your last sentences, I am pretty sure you will dismiss me. But, I have a null hypothesis to consider...
Like you implied, I think a personal threshold crossing gives this false impression that "everything changed" this month or last month or last year. Like you said, the main thing that changed in one particular month was the observer.
But, perhaps the AI epiphany is not waking up to recognize how good AI already was. Instead, it could be when an individual's standards degrade such that the same AI usage is seen as a benefit instead of a liability. Both interpretations yield the same basic pattern of adoption and commentary that we see right now.
The difference will be in the long-term outcome. Some years from now, will we see that this mass adoption yielded a renaissance of productivity and quality, or a cataclysm of slop-induced liability and loss?
I know appeal to authority can be a fallacy, but there is something to be said for appeal to a preponderence of concurring authorities. Multiple notable personalities known for their technical chops have been endorsing AI assisted coding, so it's hard to argue that every one of them lowered their standards.
It's been fun seeing the cognitive dissonance in anti-LLM tech circles as technical giants that they idolized, from Torvalds through Carmack all the way up to Knuth, say something positive about AI, let alone sing praises of it!
I have to point out that having "high personal standards" is its own fatal flaw. The worst quality code I've seen comes from developers with little self awareness or humility. They call themselves artisans and take no responsibility for the minefield of bugs and security vulnerabilities left in their wake. The Internet is held together with bubblegum and baling wire [1] [2] because artisans reject self improvement.
These same artisans complain about how bad AI generated code is. The AI is trained on your bad artisan code. It's like they are looking in the mirror for the first time and being disgusted by what they see.
>TLDR: Greg Kroah-Hartman says that last month something magical happened and AI output is no longer "slop".
Opus 4.6 has been a step change. It's simply never wrong anymore. You may need to continue giving it further clarification as to what you want, but it never makes mistakes with what it intends to do now.
If your API can run on the edge, you can get a database, function calling and user auth on Supabase's free tier. For a full Node.js runtime, Vercel's free tier is still a good option (if you don't need observability), again paired with Supabase for data.
If you can stretch "free" to "under €100 per year", then a cloud server from e.g. Hetzner will give you full control on a budget.
reply