I'm not sure what the use case is, for small tasks I have Sublime Text, for full on work, I have JetBrains. This /looks/ like a strange place between ST and VSCode
> For years folks have been asking us, “JetBrains, when will you create a lightweight editor?”
I sure never did. If anything, I want their IDEs to be more involved and sophisticated.
Otherwise I'm likely going to cancel our company subscriptions next year, VSCode is starting to overtake e.g. PyCharm in terms of developer comfort.
So I really hope this is just a tech demonstrator to renew the architecture of their proper IDEs and they'll be picking up momentum on the latter as well.
I've worked in 4 different software shops over the last 15 years. My general observation is the developers who rely on heavily automated/magic tooling are significantly outclassed by those who use the terminal + a basic text editor.
Terminal + Vim or Emacs/VSCode (depending on configuration) is not only all you need, it also produces developers who understand the systems they work with.
I know a lot of people will disagree but my advice to more junior guys is always get rid of the toys and learn the tools.
I do most of my stuff inside Emacs, but I wouldn't say that makes me a superior engineer to someone who uses a suite of JetBrains IDEs. In fact, for every benefit I gain from working in emacs and a terminal, there are plenty of trade-offs in terms of the amount of convenience I lose.
I could recreate much of this with my emacs config, but that's an investment of my own time that isn't being spent on the actual project I want to work on. So one day I'll get around to it when I feel like it's worth moving that work into my emacs environment. But until then, I'm quite happy to fire up GoLand or IntelliJ and get a complete end-to-end integration between the language and the editor, without needing to configure anything.
I'm not sure the developer who uses an IDE is worse off than someone who can wrangle a terminal and minimal editor. If anything, it's just one choice of cognitive burden over another. Nothing better or worse.
This is not my experience at all. If anything, junior or mid developers that use IDEs rarely even use all the "advanced" features like inline debugging and source control features. The more senior developers maximize the value they get from tooling.
This is a false dichotomy. You say "developers who rely on heavily automated/magic tooling" and "those who use the terminal + a basic text editor.". What of those that use heavily automated tooling but understand it? Of course people that understand stuff are better than people that don't, but this isn't directly correlated to terminal and IDE.
> I know a lot of people will disagree but my advice to more junior guys is always get rid of the toys and learn the tools.
You could make the same argument for writing assembly by hand, which will surely improve your skills. But that doesn't mean that a compiler is a toy. Those that learn and know the tools know their value. Senior developers at my work have a deep knowledge of lots of tools, because these tools can be very useful and save you a lot of time. They also build tools for others, to encode their knowledge and make everyone save some time.
Knowing what gets run is orthogonal to using an IDE. Like, you are free to not click on that green run button and use the in-built terminal console at the bottom, but even so — will vim/emacs whatever suggest me new language features that may be superior to what I know? Will it catch trivial to see problems even before I compile my program?
Also, autocompletion, in-built documentation can be a great tool to learn as well (I read much more documentation due to a quick hotkey showing me it, than I would manually hunting it down). And I know that these tools can be customized to do all these, my experience is that with so many tools they tend to be buggy and slow, and still only support a handful of features that a full-blown IDE does.
Jetbrains IDEs will step into framework/library code/stack-frames/variables that you didn't write yourself and let you trace the full context of your code ... that's insight and knowledge no straight-editor will give you.
This is the kind of stuff that sounds believable when you start programming. I can tell you as someone that read HN since high school and invested time in buyinh a t480, trying out distros, and learning emacs and vim I can say its just another hobby.
You can spend days making the best dotfiles and learning every CLI tool that doesn't mean you understand the systems you work on any better than anyone else it just means you have programming related hobbies outside of work which is a much better explanation for the correlation that you're observing. I don't know why we are inferring causation there.
Your choice of tools is not that important, but learning the features of those tools is important.
Also on giving up magic tools, as a FANG engineer you interact with many magic tools every day which you scarcely understand. It would be better if you did understand those tools as tenured FANG engineers do but as a software engineer at a big company picking your battles is the most important skill you can learn.
I learned programming with paper, pen, match boxes to represent unary turing machines, and printed out language manuals, I'm afraid you can't out-hipster me with just emacs.
And you completely miss the point: I'm fully aware that they exist, and that's the problem. Lightweight yet modular editors are such a crowded market that I don't see a realistic way for JetBrains to successfully compete in it. They don't have the same community momentum that emacs/(neo)vim have, nor do they have the resources of Microsoft. People who like IDEs are the only target demographic they have, it would be foolish to neglect those to muscle into a market crowded with very successful free products.
But they would be stupid to start from scratch. They intend to reuse all their superior intellisense, code analysis programs and make it available through a unified API for both their current tools and this newly built one.
If anything, they just want to build up a new frontend and the first look on that will be an “easy” one with a vanilla code editor.
I have to agree with you. At least in my experience this seems true (with a few exceptions). I feel that devs that rely on auto-complete and such of an IDE are never really forced to know the libraries and code they're using. To me it feels like training wheels they never take off, and therefore can never move at full speed.
But maybe it's just that due to the popularity of these IDEs, many newer devs are using them while older, more experienced devs are still using what they're used to.
Quick edit: I work with some junior devs who all use IDEs. It pains me when I ask them where some code is and they only give me the filename and not the full path. I guess this is because that is what is most prominent in the IDE.
And I've seen developers who use Vim/Emacs/VSCode spend more time doing the same thing the other guy using an IDE would have done earlier and continued with important stuff.
Although, if we go by your logic, wouldn't doing everything without an editor be even better? Because the indication and advice you're giving is that people using right tools that help their life are suddenly worse at doing their job.
For sure. I like IntelliJ, all I want is for it to be snappier; it gets pretty laggy with bigger files (like, more than one screen), it seems to have to do a lot of work that interrupts the main UI thread when it comes to redoing syntax highlighting and error checking.
I mean, the main reason why I'm not using vs code for most of my work is because it's cmd+click to go to definition isn't as good, auto/hotfixes aren't as good, and refactoring support is pretty much nonexistent.
It basically changes the jdk to version 16 (I used one from the openjdk website, not azul) where the new low-latency ZGC garbage collector is available and increases the default heapsize. Now I have a quite large project open with 1.5GB memory used, and it is really smooth all around with no stutters.
Then maybe just try switching to G1GC (available in the default jetbrains runtime) and set the ms and mx memory settings to a bit higher. Maybe even experiment a bit with the max pause time setting.
> I sure never did. If anything, I want their IDEs to be more involved and sophisticated.
Personally I want the language functionality to be involved and sophisticated, and the IDE itself to be as lightweight and simple as possible. Jetbrains IDEs come with a decent performance penalty from the IDE itself, and I think eliminating that would be a great benefit.
It's a Sublime/VS Code replacement for people who use heavy JetBrains IDE with a huge benefit of UI/shortcut consistency and sort of fluent transition between both ends.
Looks like it places itself a little above VSCode, thanks to its Intellij code engine. Also remote coding means you could have a much beefier machine elsewhere and code on a notebook on the go, for example.
