Well, Zed is a text editor with some plugins, while JetBrains products are full-blown IDEs, with abilities Zed will never offer.
None of those matter if they just close the IDE before it indexes.
> When all of these tiny issues come together, it makes me NOT want to program. I don’t want to sit around and wait for startup times to get my ideas onto the screen. I don’t want to worry that my CPU or RAM is going to be exhausted and I am going to have to restart my machine. I want to open my editor and immediately enter a flow state. I want the tooling to assist me when useful, and stay out of my way when not.
I have IDE tooling experience since Borland products for MS-DOS, and plenty of programming editors as well, between PC, Amiga, Mac and UNIX clones.
I'm certain this isn't how they think of it, but when I see someone blocking traffic while they painfully back into a spot, I imagine them imagining themselves having to fly out of there without a moment to spare, like they plan on having a drastic emergency before they leave. And if that person isn't driving a police or fire department car or the like, I roll my eyes at the delusion of grandeur.
You are able to one-shot reverse parallel park into a much narrower gap without hitting the bumpers of the cars around you or getting onto the pavement.
I'm not saying _I_ back into spaces. I generally drive into spots and reverse out of them. However, I admit that what I do is a tradeoff where I take on risk in order to have a mechanically easier time entering and exiting the space.
And then some parking spots require parallel parking which is best done via backing up anyway.
With cramped parking spaces, your real options are (a) backing into it or (b) driving forward into it. When you need to have a 90 degree turn, option (a) gives you more control over the eventual position of your car, and is frequently the only option.
However I always park with the front to the exit, since I might find myself in a situation where I have to drive away very quickly.
It might be anything from a dumpster truck about to block the street to some kind of family emergency.
I have the 20 seconds now but I can't be sure I will have them in the morning.
That's not a modern car. Modern cars do not pump oil through all the grindy bits. Modern cars need to wait for the BMC to stabilize its power.
Frozen Winters, heavy snow, diesel pumps,....
If only it was this. Usually the car transmission breaks, there are random engine shutdowns, and after restart the car just doesn't function anymore. And when it actually does start, it moves so slow and consumes so much fuel that I can't justify using it. That's my experience with JetBrains IDEs.
A car takes you to an "uncommon place in the woods?"
Taking a plane is a "common edit?"
For the majority of people a car would be the "common" usage and a plane would be the "uncommon" usage. Unless you're a billionaire taking your private jet between runways to then hop on a helicopter for the rest of your trip.
It's a terrible analogy.
Startup is definitely slower than vim though, but it's something that happens only once for me, then it stays open all day (unlike vim which I close and open repeatedly)
Zed, helix, nvim for small files in gui or terminal.
A solid Slow start IDE for solid extended time work
If I have access to a LSP and DAP, also do most of my refactoring through c tags and vim grep (or grug-far if I want to be fancy). What IDE specific features am I missing out on that can't be replicated?
Being earnest here because I always screenshare with co-workers doing a variety of things and there is nothing I ever see that is impressive or makes me want to switch.
First, that doesn't exist, and the notion's laughable.
Second, I have every feature I actually want to use in Emacs (and Zed and even *vim), and have no reason to believe that any random bullet point someone might come up with 1) doesn't exist in those editors, or 2) that I'd use it anyway.
Running gdb as subprocess, with breakpoints, step, run, continue, is the basic stuff.
https://learn.microsoft.com/en-us/visualstudio/debugger/usin...
Followed by doing some code change and hot reloading it into the debugging session.
https://learn.microsoft.com/en-us/visualstudio/debugger/edit...
While using binaries compiled in release build by default,
https://www.youtube.com/watch?v=YnbO140OXuI
All of it in C++.
I don’t have to offer my soul to make it work just pay money ;)
I'm fascinated at how vastly different our perspectives are. From my POV, I'd be shocked if VS/Jetbrains had a fraction of the work poured into them that Emacs or Vim have.
I have to manually set all of this up in Vim or Emacs, and frankly the debugging experience in GDB or LLDB is worse than it really ought to be. People actually need to use good tools to understand how nice things can be.
Just three examples out of many others.
- Automatic spring service detection
- Debugger (remote, local , with access to state, stack and ability to modify the state while stepping through), though I assume this is possible with neovm?
- built-in profiler
- can run individual tests seamlessly
- understands bytecode enhancers like Lombok
- Find Usage, find symbol, language specific navigation, showing class hierarchies, going up/down the hierarchies etc (maybe in conjunction with LSP, other editors can do a decent job?)
- Advanced refactoring (extracting classes, interfaces, inlining functions, extracting functions/methods)
- built-in database explorer
- built-in Git support (I have struggled mightily with VSCodes git interactions - but this might just be an individual preference)
- markdown/html previews
Basically, I barely have to get out of the IDE.
This is the main one for me. If I am working on a large project with decent unit test coverage, the feedback loop in IntelliJ or Visual Studio is just much quicker than the alternatives because you can run and debug the specific tests you need.
If you really wanted to you could add some trigger on save for a file that would re-run tests for said file. Maybe a plugin or key bind could run a specific test which you choose in buffer.
Zed has documentation, go-to definition/usage, local/remote debugger, can run/debug individual tests, has git and markdown. Essentially all the core IDE functionality is there. All of these work as well or better for Rust in Zed than IntelliJ.
ByteCode decompilation is a very Java-specific thing and I've not used Zed for Java yet. I suspect that they'll get around to it eventually if they don't already have it.
I've never used database plugins in any IDE I've ever used so I can't compare/contrast between Zed and JetBrains products. However, as soon as I see an IDE gain a database plugin, I know it's the beginning of the end for that IDE. After the database plugin is the CSS minimizer, the JavaScript Bundler, I guess the AI plugin is the new hip thing. For the twilight years of my IntelliJ/CLipn usage, the first thing I'd do upon installation would be to go remove all the damn plugins.
IDEs/Editors ultimately are a very personal choice assuming they have sufficient features for a given language ecosystem.
The Java LSP is a egregious "thing" that takes 10 to 30s to read your whole project for the n-th time while eating 40GiB of RAM in the process. On a loop, EVERY time you view a new file.
Where is my goddam lsif/scip support?
It was like it only had the basic language support plugin I wrote for myself at uni: basic syntax and current file/directory only source files loaded into context.
So any referenced projects, tooling, even packages in one language, and you have false positive errors everywhere.