As much as it hurts me to say this, as a fan of JetBrains and its tools, IntelliJ just seems to have become too heavy to run properly on a laptop that’s not at the very higher end of laptops in the early 2020’s.
They advised you to turn off/uninstall plugins, which I did as well. I disabled most of the plugins, even the ones that get shipped by default. For me it improved the performance a lot.
But imho you just need a more powerful computer :). You are obviously missing the features from IntelliJ :).
Precisely. This pervasive attitude of 'duh, just upgrade your hardware' comes across as elitist, and is very toxic. Not everyone can afford to drop several thousand $ every few years just to maintain a tolerable development environment.
Software bloat is ruining the world, it's a significant contributor to making people more jaded about technology and making the future seem depressing and lame.
I'm on your side, but there is not much you can do to convince Jetbrains to make IntelliJ more performant. They are adding more features with every release. You can expect IntelliJ to become slower and slower if you don't upgrade your hardware.
As a user your choice is buying new hardware, or not using IntelliJ. Paulo Renato de Athaydes decided to do the latter :). However, he states that he's missing the features of IntelliJ :). That's why I would buy a more potent computer (or one that has more fans and able to cool down good enough).
> "despite not significantly changing in functionality since Windows 3.11."
Here you can run Win 3.1 in a VM in your browser with a click: https://copy.sh/v86/?profile=windows31 and Calculator is in accessories. Make sure to put it in View -> Scientific mode for a full comparison.
Now launch Windows 10 Calculator, you'll see that it is resizable, Win 3.1 calulator can only be minimised. Win 10 shows Unicode characters like Pi, square root, superscript exponentials, Win 3.1 shows them as "x^y" and the letters "PI".
Win 3.1 has a memory. Win 10 has a history log of calculations done, a scrollable editable copyable history and clicking on the entries brings them back to do again.
Win 3.1 has a bug where (2.01 - 2 == 0), Win 10 has that fixed.
Win 3.1 has normal and scientific mode, Win 10 has normal, scientific, date calculation, multiple unit converters, equation graphing with customisable theme, zoomable scrollable live updating high quality, themeable graph.
Win 10 integrates with the Windows contacts in some way to let you share graphed equations with other people. Currency conversion pulls currencies and live rates from the internet.
Win 10 has Programmer mode which does base conversion, logic gates, bit shifting, bitwise number representation with click-to-toggle-bits for entry and viewing.
Even with a middle of the line laptop from 2017, IntelliJ is not that bad.
Disable extra plugins, do not hesitate to mark directories as 'excluded' if you don't need them to pop up in search (especially build directories), and be patient during the 5-10 minutes indexing when you switch to a new project (which should not happen often) is more than enough to get very good perfs.
Definitely not the same effect. The vscode application is much nicer than a terminal, has lot of plugins that I'm not sure exist for vim. And you can disable telemetry. And it's much faster to learn
The learning curve mostly. And most things you need are there out of the box, or very easy to install. Also plugins like remote ssh. Overall it just works without too much effort.
Remote ssh is built into vim. I think it's formally a plugin, but it's installed by default.
Of course, if you don't use too many plugins, vim is also designed so you can run it remotely. I use this sometimes to have a long-time running vim session on a remote server, using tmux or screen to reattach when I log in.
Ironically I find using a terminal inside VSCode horrendous. And since most times I need to open 2-3 of them, I have a much better experience with one terminal outside of it, and tmux.
And if you haven't tried it, use tmux.
It is the geeky tool that unlike vim/emacs you can learn in 60 seconds and immediately adds value. Whereas vim/emacs take longer to learn and get a payoff - I never managed to get to that part of the curve.
Add another 5 minutes to set up a tmux script for your development workflow!
> IntelliJ is a great product and I don’t even consider switching to anything else for professional development, where having the greatest laptop and the best tools possible should be a priority.
The title should really be "My IDE is too heavy so I moved to Emacs for hobby projects".
Yes, I agree. And to add my two cents, if you are living in a wealthy country and/or working for an established, stable firm, you should have an IDE with the world's worst case of type 2 diabetes: 8+ CPU cores, 16+GB RAM, PCIe 3.0+ NVMe. (Double is more ideal.) Gluttony! Except as a golf-like sport, I never understand the obsession with "lightweight" development environments. Like Protoss and Zerg, it would be fun to watch eSports-style coding exercises with type 2 diabetes IDE vs vim/emacs + plugins. Example ridiculous exercise: Refactor this bloated enterprisey Java mess to upgrade from Spring Framework version X to Y. Only slighly joking here, but the vim/emacs setup would be smoking at the hood. The IDE would need a few mins of indexing, then off to the races!
> Example ridiculous exercise: Refactor this bloated enterprisey Java mess to upgrade from Spring Framework version X to Y. Only slighly joking here, but the vim/emacs setup would be smoking at the hood. The IDE would need a few mins of indexing, then off to the races!
It's hard for me to come up with examples where the emacs setup wouldn't already be done in a couple minutes or using grep and a writeable grep buffer.
As an emacs user I have to say that IntelliJ (and pretty much any modern IDE) feels snappier than emacs configured to do anything comparable (lsp-mode/eglot, corfu/company, tree-sitter etc).
While IDEs may require more resources, they usually utilize them better.
Emacs is fundamentally single-threaded and not great at async things. With most of the logic written in a very slow non-JIT friendly language with naive blocking GC. Rendering pipeline is also a mess. Underlying internal datastructures are also very naive (which is a good thing when you implement things in C).
Things are slowly changing. emacs now is a lot better than 5 years. So may be in 10 years it will really rival more modern competitors in terms of performance.
Having said all this, emacs universality and extensibility keep me with it.
The asyncness of Intellij IDEs annoys me at times. I'm used (from emacs) to bashing out a series of key combinations in the expectation that the effects of one will be complete before the next is processed. There are cases in Intellij IDEs (can't remember specifics, I'm blissfully back in emacsland and don't anticipate using an IDE again in the near future) where that can result in the later keypresses being processed before the window pops up or whatever from the earlier ones.
Just a minor annoyance, really. It would be nice for emacs to improve on the async front, but synchronicity does have its benefits when interacting with humans. I sometimes find the lack of asynchronous behaviour annoying in emacs, but not very often despite using EXWM (so locking up emacs means locking up the window manager).
E.g. I'm in insert mode, then I press esc to go to normal mode and press j to go down one line. Instead, j is inserted.
I can't be sure I didn't just make a typo, but this has happened much more often in Intellij than in vim proper, so I think there is something going on where IDEA has a hiccup and scrambles or eats some inputs.
This is a major annoyance in Visual Studio. You have to stay all the time waiting for feedback from the software, otherwise your commands will get processed on the wrong order.
And yes, autocompletion fires from many different keys, and if it misses the keys order, it will automplete into some completely different code.
Doesn't lsp run in a separate process for other editors as well? I've only found emacs slow for larger Java projects in the past, using eclim, and font-locking very large javascript files. But the new lsp-java seems to have cleared that up, and I'm not sure what changed w/ javascript-mode, but it also seems much faster since a few years ago.
Yes it gives us both a super-predictable queued operations model for using emacs, and serial operation in a parallel world. Years ago when single core performance was king this wasn't an issue, but now we're stuck having to optimize the long hot path.
Since you mentioned the single-threadedness (and it’s relevant to the discussion of IDE/Emacs): what’s the status of any initiative to move Emacs to multiple cores? I’m single, and I hope to one day have a family etc.. If I end up staying single for long enough, helping move Emacs onto multiple cores is something I fantasize about contributing back to the community that has helped my life so much.
Most of what Emacs does just won’t benefit from massive parallelism. CPUs are ridiculously fast at processing text (AVX2 instructions can process vectors of 32 bytes at a time), and most of the stuff that _can_ benefit from parallelism should just be moved to an external process. For example, querying your compiler for a list of methods that apply to the current object, or a list of functions that start with “Foo” are mostly moving to external processes using LSP as the communication protocol. It would be nice for some things to use background threads, like Gnus polling your IMAP server for email, and Emacs does have the threading mechanisms to handle that now. It’s just a matter of time before someone does the work :)
Hey! Exactly the response I was looking for. Thanks for this.
Your response reminded me of an Intel project about regular expressions. I think it’s called hyperscan, but I’m not sure. It’s a regex engine (I think that’s the correct terminology) that makes dedicated use of very specific Intel instructions to reach incredible regex speeds on Intel processors. Would be cool if Emacs could make use of this tech when configured properly. I bet there are some internals that rely on regex.
I disagree. When I am running a compilation (with output being dumped into a visible buffer) + query magit for large commit. Over tramp. Things noticeably freeze. Technically it all is async. Practically, it is implemented as polling things on main thread with some witing happening in non-async fashion.
> For example, querying your compiler for a list of methods that apply to the current object, or a list of functions that start with “Foo” are mostly moving to external processes using LSP as the communication protocol.
That's why we have lsp-bridge and lsp-mode emacs fork :) Both of which build some infrastructure to avoid doing communication work with lsp-mode work in main emacs thread. So, heavy emacs users are building some async machinery which wraps another already async and relatively lightweight protocol, because core emacs facilities can't keep up with it. Architecturally it is kind of insane.
I think, lsp-mode fork is doing the right thing (from practical POV; it goes against "emacs is just an elisp interpreter" ideology though) and hope it gets into core at some point. A better solution would have being having first class async and background threads support at the elisp level. Which would never happen due to elisp messiness.
Emacs has support for multithreading (threads landed in 26), there was an article about the multithreaded model earlier this year (https://news.ycombinator.com/item?id=31559818), and the Elisp manual has a section on concurrency (section "Threads").
If you want to contribute to the future (pun intended) of multithreaded Emacs, your best bet may be to make a library that adds the nice concurrency facilities that will help library authors move to a multithreaded model. An actor model, green threads, or supervision trees may be avenues worth pursuing.
A big blocker is probably the dynamic binding, but trying to "fix" that would break a lot, if not all, of the existing libraries.
Thanks for the pleasant surprise of encouraging feedback. I’m going to send this comment chain to my email inbox so that I can find it later. This is great.
It’s such a monumental task to hack on the basics of the text editing. I listened to a tts book; I think it was titled “The Art of the Text Editor” that delved a bit into some of the original philosophy of the text rendering etc. in Emacs. You might enjoy it If you ever need a boring book to read.
You probably mean The Craft of Text Editing -or- A Cookbook for an Emacs. I've skimmed it a bit before and it's on my reading list. First I'm still working my way through CRLS's Introduction to Algorithms and Aspnes' Notes on Data Structures and Programming Techniques.
I really wish I had the capacity and capability to pursue this effort. I barely have the energy to be good at shitty DevOps and Terraform, writing basic Python and Node is so time consuming. I can do some Lisp, but only at the basic level of init.el and adapting a few configuration examples.
I do the good thing and donate to the FSF monthly but I wish I could donate directly to Emacs because I use it every day. Even better would be to sponsor the development of a concurrency library and port of major things like magit or org.
I've requested this whenever I've had the chance. I would be very happy to donate some cash to get core Emacs improved. Emacs has made a huge positive difference to my professional life for years. Unfortunately this is not made easy.
I think one of the issues last time I looked into it was that FSF couldn't have donations on a platform that was potentially tarnished by having e.g. non-free javascript running on it somewhere... All very correct and in tune with their mission I'm sure, and part of the reason why Emacs etc. has been so successful, but it would be nice if they were a bit more pragmatic occasionally.
Please DON'T use the threads. As of 2018 it has many data races (https://nullprogram.com/blog/2018/05/31/), and resultant bugs will be a nightmare to track down.
The Emacs community has always got by through finding other ways to ensure responsiveness. It's true that each individual user shouldn't have to spend that much time on configuration (Doom Emacs and such distros help here), but still: people who find it slow must have misconfigured something, and on profiling, they'll find at most 1 or 2 features of their config that's eating all the CPU cycles. These won't actually be hard to fix, for a programmer, and threads wouldn't have helped matters, and at best only have hid the CPU-eater.
Yes, that post was mentioned in the article I linked:
Even Emacs current threads library suffers from data races which is one of the reason I believe it has not seen much adoption.
(where suffers from data races is a link to Chris Wellons' post).
The idea now is, as Chris states:
There really needs to be a safe, high-level API with clean thread isolation. Perhaps this higher-level API will eventually build on top of the low-level threading API.
While you are right that for 99% of standard usage single-threaded code is entirely fine, not utilizing between half to 15/16ths of potential processing power is a bit of a shame, especially considering it means doing something like indexing an entire project (yes, we can use GNU Global) will require the user to just sit and wait.
That "99% of standard usage" is the kicker, isn't it? The greybeards who opposed multithreading since the beginning tend to say that the remaining 1% of use cases is best done in an external process, ideally not even written in Emacs Lisp, so that Vimmers and the rest of the free software community can benefit. The GNU Global you mention embodies that ideal exactly.
I suppose if you still want that program to be written with Emacs Lisp, you could use async.el (https://github.com/jwiegley/emacs-async/) and there's finally an use-case for the threads: it'll be relatively safe to run those 16 threads only in the external Emacs-process.
This is awesome! I use it since initial "gccemacs" announcements.
It is still order of magnitude slower than JS. Dynamic binding, ability to redefine or advice any function and fundamentally cache-unfriendly core datastructures (cons-cells) and absence of JIT hotspot optimization do not help to catch up with competition :(
Yeah, Emacs's performance isn't really that great when going head-to-head as an IDE. Yes, it uses less memory and disk cache, but if we're talking about, e.g., working on a large Rust project with Emacs+lsp-mode/eglot+rust-analyzer, you're going to be in the ballpark of IntelliJ for memory usage, and the responsiveness will be nowhere near it. I will say, though, that the disk usage will be much less, and that has mattered for me on this 256GB disk MBP- between Xcode, Docker, and all these package managers for various languages, my disk space has become a precious commodity.
I still like Emacs. I prefer free software. I love Magit. But, the UI responsiveness is honestly frustrating when using LSP.
Try to determine which one you're using by running "M-x linum-mode" and then "M-x display-line-numbers-mode". Note that you can use both at the same time (which would make zero sense: it's only to troubleshoot which one is problematic for you).
Do not use linum-mode anymore.
I can display buffers with hundreds of thousands of lines while showing the line numbers (Emacs 29 / native compilation / display-line-numbers-mode / CPU is an AMD 3700X with 32 GB of RAM) and Emacs is ultra responsive.
This is the kind of thing which infuriates me the most about emacs. There are thousands of similar but not equivalent ways of doing the same thing, both StackOverflow and the emacs wiki contains some (but not all, and not the same, and usually not the right, and usually contradictory) ways of doing things. And it's impossible to figure out which way is the right one without asking around in IRC channels.
Why oh why couldn't they improve linenum-mode instead of introducing a new mode.
Wouldn't most of the slowness and memory use be due to rust-analyzer itself, which is notoriously slow and heavy for large projects? That has little to do with your IDE choice. Emacs devs are also working on tree-sitter parsing support, which might help reduce reliance on LSP more generally.
Emacs was built as a TUI, and it is built like a giant REPL; read input, evaluate command, print the output, and loop back. IDEs based on "modern" GUI frameworks (IntelliJ uses Swing, not exactly "modern") are inherently multi-threaded; you have the UI (or "main") thread that accepts events and updates the display, and ideally never blocks, while evaluation is performed on worker threads that can be canceled or scheduled as needed.
In practice, you can get far with Emacs' process supervision to avoid blocking the command loop, but some things that are trivial to offload to a worker thread are next-to-impossible to avoid blocking in Emacs. One of those things is parsing megabytes of JSON from an LSP server into Lisp data structures, which is baked into the Emacs core and will block redisplay.
Yes and no. I'm using rust-analyzer as an example, but I also use other language servers and observe similar UI lags/stutters.
When it comes to memory, my point is precisely that we should count the language server in the total and not just the Emacs process. So, when some other IDE is using multiple GB of memory on my Rust project, we have to compare that to my Emacs + rust-analyzer memory usage because both of those processes are providing the features that other-IDE is providing.
However, Emacs is also still kind of laggy when using LSP, even though the actual LSP server lives in another process and communicates mostly asynchronously. My understanding is that there are still bottlenecks in Emacs that make this not truly async. But, even if my LSP server of choice is extremely slow, why should that affect my cursor movement or typing speed in my Emacs buffer? I can see why it would be technically difficult to make it NOT introduce some lag, but it shouldn't in principle.
I haven't used Visual Studio Code, but my understanding is that it is plenty responsive to typing and cursor movement, even while using rust-analyzer.
I tried to switch to emacs but couldn't find an introductory tutorial that was written for mere mortals.
Currently use vim, or things like gedit and kate that come w/ a DE. I would really like to learn to use emacs, but the last so called "beginner" tutorial I tried started with _learn a new lisp dialect so you can write emacs extensions_. Seriously.
Does anyone know where to find a tutorial that teaches you how to do things like open a file, type some stuff, and save the file?
Maybe show whitespace change highlighting modes and a few hotkeys if I want to get fancy... but like otherwise normal beginner stuff?
Aside from the built in docs, mastering emacs is quite beginner friendly.
It's aimed at people with prior programming experience, but not any emacs experience.
You can get a few chapters for free.
Submitted a bug report regarding poor performance like 2 years ago and they are still "looking" into it. I guess the shiny look has priority over performance for them.
They definitely don't seem to care about performance or bugs very much, but it should be noted that the latest version starts up much faster even from cold storage. I used to look at the splash screen for ~8-10 seconds, but not anymore. It was the first significant performance improvement in a very long time.
Other than that, I agree with you. In addition to well-known performance issues and longstanding bugs, I'm also still waiting for features like full Wayland support that was promised by the end of 2020. I mean, I understand it's not on their highest priority, but why promise things you're not actively working on?
I'd suspect that it is a combination of the following:
a) a lot of existing code that needs to be untangled (e.g. moving various tasks to not depend on indices);
b) figuring out how to avoid unnecessary re-indexing (e.g. the downoadable index caches for things like Java files);
c) having to define a migration path to spread out breaking changes to give plugins enough time to adapt.
IIUC, some of the performance work with the latest version is due to parallelizing the various background processes, which uses coroutines, so you could add "implementing language, library, and tooling support to Kotlin/Java" to that list.
I also find intellij idea (and friends) too heavy. I am using it only when developing java or kotlin because the experience is much better than anything else, despite the slowness.
For anything else (python, js, elixir) I use VSCode with a careful selection of plugins. It works very nice even on my Thinkpad T420.
I agree with the people that said that if you install a lot of plugins (lsp etc) on a bare bones editor it will feel very slow; I had exactly this experience using vim on Windows: Using it as a text editor with only a few plugins (fzf etc) was great but when I started using is more like an IDE the experience wasn't that good anymore resulting in choosing VSCode instead.
> I wish Elixir support wasn't just one guy from Jetbrains working on it in spare time though...
Better that than the travesty they did to the intellij-hcl plugin, where they .. hired? in-housed? I don't even know what they did to that plugin except completely and utterly broke it and made updates to it go into this weird black hole
> The shortcuts are just unergonomic in my opinion
Extensions -> type "emacs" -> done
I really hate this articles that scream "look I'm so old school I use vim/emacs" while emacs is a single threaded nightmare that will work worse than any IDE if you will try to configure it to make it usable for actual every day work.
I abandoned JetBrains a long time ago.. too bad, because they always have really good language/framework/platform tooling, but I just can’t stand the IDE.
I don’t see them just creating a language backend for VSCode.
The OP would probably find that any IDE works just fine on the baseline MacBook Air from the Apple Silicon era. But anything older than that is probably going to have problems.
Many people like to work on hobby projects, and hobby is usually done at home or somewhere else than work.
It's also not recommended working on personal stuff with work's hardware and means, you risk losing your hobby projects to your company.
And during work time, you are supposed to work on things the company told you to do, not personal stuff. If you are planning to do extra hours for that, why should it matter where you do it?
Your comment probably seems non intuitive to many of us for all these reasons.
You are assuming everyone should reach your conclusion. Some of us have been programming for a living for years and still like programming outside work. Because for instance you get to build whatever you want under whatever condition you like.
My employer pays me to work 37.5 hours a week. An excessive amount of hours beyond that would raise potential legal issues, as there are limits on how much overtime is allowed.
And yes, people do things for fun, too, not just for money.
I think I speak for essentially everyone here when I say, "fk this guy's boss". Old mate here in this thread slacks off or 2 days, his boss is already very respectfully thinking of firing him.
It's not 1920. The modern middle manager has more invested in his fantasy football league than his direct reports -- and by some magnitude. Grow up.
Are you serious? If anything, the boss should be happy someone is improving their skills on their spare time instead of learning everything on the job.
A code monkey is not selling their programming skill to per employer, person is trading hours spent doing work-related tasks for money. Once the agreed amount of hours has been filled person can do whatever person want (without reasonable bounds, of course) and does not have to think about per work. If per employer wants per not to program outside of work, per employer could offer a contract stipulating that, but I would expect person to seek a rather sizeable remuneration afore accepting such an offer.
> On my top-of-the-line Mac M1 with 64GB of RAM and 10 CPU cores, everything feels lightweight and smooth [...] But when I am at home and want to work on a hobby project, I prefer to use my less powerful laptops [...] after just an hour or so writing code and running tests using IntelliJ, the laptop becomes unusably hot. The fans get louder and louder until it’s really annoying.
To add my anecdotal evidence: I have a relatively new Dell Core i7 laptop with "only" 16 GB of RAM, and while using IntelliJ IDEs "normally" (i.e. not while it's updating its cache), the CPU usage rarely goes above 5%. So the impression that you need top of the line hardware for running IntelliJ products that the blog post is giving is a bit exaggerated...
There could be some kind of limitation on Apple's chips, there are complaints across the Internet of IntelliJ being slow on Mac despite the power of the M-series SoCs. It could be that there are optimisations to be made in their JVM for generating ARM code.
Disabling plugins helps a lot, though. On install you'll get a screen that let's you select tons of features that had me going "gimme gimme gimme" but in hindsight I've never used 90% of them. For example, Android support is a major plugin I've never used with Idea because Android Studio exists and seems to integrate much better. Disabling that cut down startup time by a noticeable amount when I last culled my install.
My experience with tricked out command line editors has been that they start out blazing fast but as you add more and more features (syntax highlighting, linting, etc.) they become slower than your average IDE. They're still responsive when they're not doing anything, but sometimes they just need a few seconds to think, breaking up my work flow.
Another issue that I've seen some people run into is that IntelliJ will index all your files. If you have some kind of process that slows down your computer when you're opening tons of tiny files (say, an antivirus program or a project stored in a hard drive) that can instantly kill your work flow. The only alternative seems to be to postpone loading all the files until you start searching (which VS Code seems to do) but then you're just moving the problem around, not really fixing it.
It's what I get for using a text editor for an IDE, I suppose. My experience with Jetbrains tools is that they're a lot more powerful than most of the competition at the cost of some minor input latency during heavy operations such as indexing.
I am using a seven year old ThinkPad T550 with 16MB and onboard graphics, because I know that if it runs fast on my machine, it runs fast almost everywhere else. IntelliJ is very usable with that configuration, except the terminal (as I wrote in another comment).
I switched three years ago and I'm happy with emacs still. I don't find I miss anything jetbrains used to offer me. I might feel different if I spent a lot of time profiling, the one area where an IDE generally has a leg up - but IME the profiling experience in anything that isn't visual studio is bad anyway.
Well, the author says "trying to get back" (emphasis mine), which makes me think that there is some prior experience, it's not "has only started." The article also says:
> Over a couple of years, I have managed to configure Emacs with most basic modern shortcuts that work in most other applications post the 1990’s (small things like Cmd+S to save, Ctrl+Tab to switch buffers etc.)
which, on the other hand, sounds a bit weird to me. It states that there are years of experience with Emacs, but it wouldn't take years to configure small things like Ctrl+Tab. These are things people use very frequently, so I would imagine one would configure it within the first month, or even the first week, of using Emacs to reduce friction.
XEmacs was my IDE when UNIX environments didn't offer anything better, and most likely Emacs nowadays has implemented most of the stuff that XEmacs had going for it over Emacs.
So it was my "IDE" between 1995 - 2005 when working on UNIX, muscle memory is still there and I still remember basic elisp stuff, yet I see no reason to abandon my IDE's, now that they are available everywhere that matters to me.
I recently started using intelliJ's datagrip. For some reason, it stores its metadata in xml files, 150Mb or so per database. One postgres DB cluster it actually refuses to index unless I select only some of the DBs in it. Mind you, these databases are not particularly big, e.g. 17GB for the cluster it doesn't want to index.
When it starts up, it loads all this metadata in memory. You feel the laptop being slow for a minute or so. After that, its mostly a good tool. Once in a while, it indexes something and grants you another coffee break.
I keep wondering, why XML? If you build this much metadata, wouldn't it make a lot more sense to store it in a database itself, and only load what you need from it? Say sqlite or h2 or something.
Not complaining about the xml vs json vs yaml vs csv thing. It's more that when you choose XML, you've chosen streaming and reading it completely. There is no way to read it partially and only use the little bit needed.
DataGrip isn't perfect but it's radically changed how I work with SQL. It makes writing queries so incredibly easy, with a god mode autocomplete. JOINs are so easy <3
Does anyone knows of vim or emacs plugins that do similar heavy lifting? Preferably decent at T-SQL
I don't know the impact on battery, but there's a Power Save mode in Jetbrains IDEs that makes the IDE slightly snappier, when you just want to read some code or do one or two modifications.
I highly recommend the Geany IDE as well, it's very simple and lightweight, but still has conveniences like an integrated terminal if you like, automatic state saving, etc. Best IDE in my humble opinion!
> running the community edition of Jetbrains’ IntelliJ IDEA
...
> As much as it hurts me to say this, as a fan of JetBrains and its tools, IntelliJ just seems to have become too heavy to run properly on a laptop that’s not at the very higher end of laptops in the early 2020’s.
IntelliJ does what I want, but only barely. The autocompletion gets it wrong as much as it gets it right and it is a performance hog.
I can deal with that.
The problem for me was JetBrains' privacy policy[0]. It is loosely-worded enough to forbid them practically nothing, and I find that especially appalling in a so-called "community edition".
So I began searching for alternatives. Emacs may serve for OP but I always forget how to exit it so I wanted something with a clickable "close" button in the top right.
I am getting a good initial impression from Codelite[1]. I'm sure Codelite doesn't do everything IntelliJ's IDEs do, but it has the functionality I use and it is a breath of fresh air after waiting for IDEA and the like to catch their breath during text editing.
> The problem for me was JetBrains' privacy policy[0]. It is loosely-worded enough to forbid them practically nothing, and I find that especially appalling in a so-called "community edition".
What, specifically? Because I can see they are bound by the GDPR and it seems clear to me:
> If you install on-premises products such as IDEs or .NET & Visual Studio Tools, these products are located on your hardware. JetBrains does not provide hosting for these products and does not have access to any of your data processed with these tools, unless you actively decide to share this data with JetBrains.
> I wanted something with a clickable "close" button in the top right.
c'on! Last time I checked (2 seconds ago), Emacs' GUI has a "close" button in the top right. And a "File" menu at the top left with a "Quit" entry, that teaches you the shortcut (C-x C-c).
Emacs in the terminal (emacs -nw) doesn't have the top right button but still has the menu. We can't click it by default though. Use: F10, or M-x menu-bar-open, or M-x xterm-mouse-mode and click on it. https://www.gnu.org/software/emacs/manual/html_node/emacs/Te...
Menu bars are the most amazing GUI paradigm ever invented and whenever I see an Emacs "distribution" which disables the menu bar it kind of feels to me like they would say things like "fire? We don't like that," or "the wheel? Not really a fan of that."
A long time ago I switched to Emacs(with evil mode) from whatever IDEs I was using but it was also way too slow. I then switched to vim and configured it with lots of plugins. This was the best thing ever. I transitioned to Neovim but Vim would also be OK.
Vim/Neovim are always fast. Even with 30+ plugins configured. I can run them on any hardware and they are blazing fast. Not to mention the superiority of modal editing if you are used to it. I have every feature I need (LSP/code completion/diagnostics/even debugging via DAP).
Pretty sure that I won't switch setup for a long time/ever again.
https://spacevim.org/ is also good alternative , it is basically vim/neovim sensible plugins pre-configured with smaller config file and simpler management.
I suggest that everyone go through this journey before using Neovim: https://www.chrisatmachine.com (so you can understand how and why something works, and also fine-tune your setup). Chrisatmachine's setup as for me looks similar to AstroVim.
Oh this feels like spacemacs
I already use evil mode spacemacs I think the most important feature is org mode but maybe I’ll play with spacevim over the holidays!
There are many of these distributions and I recommend them to people new to Vim because they can get a good out-of-the-box experience.
However after some time you probably want to configure your own and only include what you truly need. For this a good solution is to just adapt https://github.com/LunarVim/nvim-basic-ide to your liking. This is made by the author(s) of LunarVim.
This sounds like exactly what I wouldn't do?! I actively stay away from IDEs because the are bloated and slow and don't offer me personally anything that I am missing in my (configured) Vim.
I have used JetBrains in the past and I never was a fan. It is very slow and lagy in many situations. If I'd go the "IDE" route vscode would be my choice.
Same here except that each year it seems like
I shed a plug-in that I’m not using anymore. Over the last decade I’ve been told over and over whenever I join a new team that Vim isn’t going to cut it and I should switch to the current hotness. Invariably, I give the new hotness an honest shake and can’t suffer the productivity hit. My favorite is when someone promises me that the “vim bindings” are actually really good.
What I think people don’t get is that it’s not just Vim. You can add hjkl to another editor and it doesn’t make a difference. The terminal is my IDE. I run vim within tmux side by side with a shell, and I’m way faster at grepping for something than IntelliJ is at indexing and searching. My editor never has a few-second lockup. I never depend on the IDE to build my code, so when I work on something there’s a functioning Makefile or equivalent and it’s inherently ready to build and test on CI.
I don’t care about Vim vs emacs. I’m sure emacs is great if you’ve invested in it like I have vim. But contrary to all the IDEs and editors I’ve been urged to switch to over the last ten years, vim is still kicking and I keep getting better with it. If I adopted the new hotness every few years that wouldn’t be the case. You can pry vim from my cold dead fingers.
What Jetbrains provides, and is quite hard to replicate, is the linting and auto-correct suite for medium/large/enterprise development teams.
That's actually the main thing, deep and wide integrated linting.
Almost everyone does autocompletion (up to a point).
Almost no one does linting as well as they do.
Quick experiment for you.
Take a big source code file you've worked on, preferably solo, so you won't have excuses :-p Not a "best case scenario" file you've cleaned up and polished. Be honest with yourself, something big and reasonably messy where the deadline was tight or the issue was complex.
Open the entire project and configure it in a Jetbrains product.
Open that specific file in the IDE.
My guess is that the top-right green checkmark won't be there.
You just can't hold all that stuff in your head at all times.
That's why we use computers and tools (such as advanced IDEs), to remind us of this stuff.
Anyway, in the rare case that you actually do all of that on your own, <<you>> are an outlier. 1%, 10%, for sure you're not lower than 50% of developers. The majority of developers need that help.
That's an expensive experiment to try, so I probably won't do it, but what does the green arrow checkmark mean? That my code lints? I use Syntastic most of the time, which just runs a linter like flake8 and then puts a red arrow next to offending lines. It runs every time I save, and I generally take its feedback right away because the slight shift to the right when the arrows are present nudges me to fix them.
Definitely not saying anyone else should use Vim if they don't want to, just that Vim is part of my productivity superpower and I take offense to it when part of the onboarding experience is setting up an IDE and someone really pushes it on me.
Yes, the green checkmars means that the code is lint-free (up to a point).
The Jetbrains linters are proprietary, though they can integrate Open Source ones, and generally better and more thorough than Open Source ones. They're especially better for professional development where you use various frameworks.
> I take offense to it when part of the onboarding experience is setting up an IDE and someone really pushes it on me.
That's fine, but being a part of a team sometimes requires sacrifices. It's as true in football as it is in software engineering :-)
Plus I'm sure reasonable teams just leave you alone if you do your job well and your setup doesn't intrude on what everyone else is doing.
For my day job I mostly write Go. There are tons of great linters you can use with golangci-lint e.g. which is easy to integrate into Vim. I wouldn't see any benefit of using Jetbrains here.. maybe it is true for other languages that don't have good community linters but I think there are not many of these..
I was about to say that. I used to work with python/django and pycharm really does a lot of heavy lifting on the autocomplete/linting part. It knows django and would autocomplete even django's ORM params (which are quite dynamic).
Now I moved to Go, and that is not needed anymore. Most thing are already bultin or can easely be extended (like with golangci-lint). It's static typed with simple OO model which makes things a lot easier. Since then I've been working neovim and I don't feel I miss anythig from full-featured IDE.
I came across LunarVim not long ago and it helped me go from just using neovim for quick edits and editor keybindings to going down the path of fully using neovim.
I still use IntelliJ for Java, but for everything else neovim is working well. I still have VSCode for a fall back.
Speed definitely depends on use cases. I switched from Vim to Emacs because Vim's syntax highlighting in LaTeX files was so slow it lagged behind my typing (and I am not a fast typist!). This is a well-known problem in Vim and the manual even has a section about it (see :help tex-slow). Emacs was perfectly snappy for LaTeX and I didn't want to use one editor for LaTeX and another for everything else, so I just switched to Emacs for everything.
I'm not sure what you mean. If you are asking whether either Vim or Emacs use treesitter for syntax higlighting of LaTeX files, the answer is no at least not by default.
I think the cycle repeats itself, there used to be bloat-wares like Eclipse (IntelliFuck) that programmers would swear by. Then came Sublime and people had a revelation about how light and fast an IDE can and should be. Recently there has been another wave of hipster programmers swearing by bloat-wares like VSCode.
Now people have to rediscover Emacs from 47 years ago.
What do you mean, doesn't every IDE need its own Infocom-esque text adventure, psychoanalyst, IRC client, web browser, Morse code translator, ASCII art drawing tools, and Tetris implementation? Of course all that bloat is an acceptable price to pay for the best editor available.
Anything that does syntax highlighting, jumps to definition and allows you to install additional packages/functionality is an IDE and everything else that you call an IDE is actually bloatware (see, I can do that too.)
No, I don't need to freaking have a goddamn FTP and SSH client built into the tool that I so heavily rely on every day just because there is a use case for it in someone's brain that is orthogonal to the vast majority of its users'.
I love emacs. I don't use an IDE unless I'm forced to, mainly because I simply don't use the features most IDEs offer, and have considered them bloated nightmares since the first time I used one. Emacs has everything you need, and is fast enough, with few exceptions. Same for vi(m).
I'm still on Sublime Text, after briefly switching to VSCode. Unless you're on latest-gen hardware it seems that most feature-rich IDEs are just terribly laggy, which drives me nuts. A computer just shouldn't need several seconds to load and parse a source file even if it has 100.000 lines. Editors like Emacs or Vim were always too low-level for me though, Sublime is a nice compromise between simplicity and speed.
All the plugins, The synced user configuration, github copilot, git integration (although I do use sublime merge a lot on the side), I used to work on a remote copy also via SSH (and I can't remember what plugin), there's just so much available out of vscode now, I feel like every new months it ships new features while sublime text didn't come up with an update in years.
For me it is the plugins, themes, icons etc. As soon as there is a plugin you can't live without, there's no way back. I can't remember which one it was for me but when I saw a co-worker using it I had to give VS Code another try.
Migrating over is easy too as you can import your shortcuts with "Sublime Text Keymap and Settings Importer"
I'm in the market for a new IDE as Atom is end of life (prev. Sublime)
I tried VSCode and went back to Atom -- it still works fine but expecting that won't last
Ideally I really need one where I can run bash sessions in tabs alongside code, I don't really use autocomplete and such -- but it needs to handle a lot of open large files with zero lag and instant search
I switched from Atom to VSCode a while back. Code has better extensions and is faster. Only thing that bothered me is the missing Git view on right side. But now Code lets you have a Primary and Secondary sidebars. I keep Git on right side and File Explorer on left side
I moved from Atom to VSCode a few years ago. It's a worthy successor, in my opinion.
What were your blockers to moving to VSCode? My remaining issue is to be able to css style any element of the UI like I could with Atom. There're plugins that let you monkey patch to get that feature, but updates to VSCode break them.
Too many windows, panes, misfeatures I don't want, and it's also quite slow.
It's a kitchen sink even before you install any plugins, and yet all the useful functionality requires plugins.
All I want is a text editor that can quickly switch to another file, that doesn't make it annoying when the file it had open was changed, that only adds the input that I type to a file and nothing else.
Also easy integration with commandline tools (select text, pass that as stdin to a command, replace it with stdout, all done trivially without going through a billion menus and plugins), vertical selection and multi-cursor that doesn't suck, maybe a few other details, are things where it failed to deliver.
> A computer just shouldn't need several seconds to load and parse a source file even if it has 100.000 lines.
Why? It doesn't just load the file, but also analyze it, find flaws and put it into a bigger picture which assists the user. And you don't need a last gen for this. I work on a 10 year old machine quite fine with a rather heavy IDE-Setup. Just accept that a computer can be your partner, helping you to reach your goal, and that he needs his time for doing his work too.
The lines are all interconnected. Whether you view them or not, they still influence each in some way or another. And figuring this out is the hard part in coding and software-design, which the computer takes care of and assists you.
All the lines being interconnected is a rare edge-case. Often there are multiple independent top level expressions in a file. Talking about code here, because that is the most common thing that needs to be highlighted and where lines influence each other potentially.
To make a simple example: Have multiple functions defined at the top level of the file? Great! Independent parts!
Of course it could be, that in one function another is called, but does that have to affect highlighting? Immediately?
The code model still needs to be built from the entire file, which I suspect is what most of the slowdown is when using an IDE (not highlighting, although the code model can inform advanced highlighting e.g. different colors for local vs instance vars).
Well, that is no justification for any slowdown. The "code model" does not need to be complete the moment I start an IDE or open a file or project in it. A temporarily incomplete model is very acceptable. More work can be put off to a background thread. It can be delayed until I perform the first action, that actually needs a complete model, like say a renaming of something. There are relatively few actions like that. Many facts can already be concluded from import statements in various languages.
Furthermore we are fighting a strawman here: Who in their right mind opens a 100k line code file in an IDE? And who in their right mind creates such a disaster in the first place? This is not a realistic scenario we are talking about here.
I love these weird, artificial "no true Scotsman" arguments that appear on HN when people are discussing little more than the colour of the bike shed. "Oh, but how does it do with 100k lines?" I can already tell you from my lovely, bloated IDE: Terrible. And, I don't care. Why? WTF is this file 100k lines!?
I know at my workplace, the vim&emacs-users are the reason for the codesinks here. They have no relevant penalty for growing everything in singles files, but they have some benefit as they can navigate code better with a poor setup. And at some point, reasons like "not destroying the git-history" and such are added to the list. And laziness might be another reason on that list.
I took the same journey. I switched from Sublime Text to VSCode and stuck with VSCode for months, and depending on project du jour I've done this a couple of times. For me its mostly speed and a number of small, but frequently encountered, quality of life issues that keep me coming back to Sublime Text. Some of the small differences around cursor/multi-cursor management never stop irritating me in VSCode compared to ST. Also, I do a lot of PostgreSQL related stuff and I've yet to find a syntax highlighter that's 1) just syntax highlighting; and 2) able to handle things like dollar quoting well for VSCode where in Sublime Text I've had such highlighting for years.
Sure it doesn't see frequent updates... but so what? That might well be a strength since some kinds of changes can be low value & highly disorienting. The plug in eco-system isn't as broad as that for VSCode, but unsurprisingly there's more cruft there, too.
Ultimately your mileage will vary based on your preferences, but I'll stick with Sublime Text until there's something really more compelling.
First off, thanks for years of productive development with ST. I really enjoyed using your software for a long time and it carried me through a significant portion of my early career.
It was a bug where selecting some text and using the key shortcut to multi select the next instance would select incorrect text for certain strings. It was a while ago so I don't remember the details, it may have been some combos of whitespace and non-alphanumeric characters.
It wasn't the only reason, but it was the final impetus to try some other solutions.
I don't really know what you do with your text editor, but Emacs (and vim) are very much not "low-level" editors unless you chose to not configure them.
Emacs has all the features of VScode, plus more. And it keeps expanding by each day. A "fully featured" Emacs "IDE" is also just as laggy, sometimes even more, as any other "fully featured" IDE. Some Emacs configs even take tens of seconds to load! Mine however takes 1.5s, but that is because everything is lazily loaded. The first time I open a C++ file, it takes a couple seconds.
A really nice easy to use framework for getting productive in Emacs quickly is Doom[1]. You should give it a peak if you think Emacs is "low-level".
One of only about three things I miss from switching away from Windows, is that I now have to use Sublime instead of Notepad++. It was just so much better at dealing with large files and batch operations, which are a priority for my work. But Sublime has beat everything else I have tried out on Linux, and obviously has features Notepad++ does not.
294 comments
[ 0.23 ms ] story [ 240 ms ] threadBut imho you just need a more powerful computer :). You are obviously missing the features from IntelliJ :).
Or maybe we need to stop tolerating performance creep and resource bloat?
As a user your choice is buying new hardware, or not using IntelliJ. Paulo Renato de Athaydes decided to do the latter :). However, he states that he's missing the features of IntelliJ :). That's why I would buy a more potent computer (or one that has more fans and able to cool down good enough).
These days, Windows Calculator takes over 20 MB to run, despite not significantly changing in functionality since Windows 3.11.
How did we get here?
Here you can run Win 3.1 in a VM in your browser with a click: https://copy.sh/v86/?profile=windows31 and Calculator is in accessories. Make sure to put it in View -> Scientific mode for a full comparison.
Now launch Windows 10 Calculator, you'll see that it is resizable, Win 3.1 calulator can only be minimised. Win 10 shows Unicode characters like Pi, square root, superscript exponentials, Win 3.1 shows them as "x^y" and the letters "PI".
Win 3.1 has a memory. Win 10 has a history log of calculations done, a scrollable editable copyable history and clicking on the entries brings them back to do again.
Win 3.1 has a bug where (2.01 - 2 == 0), Win 10 has that fixed.
Win 3.1 has normal and scientific mode, Win 10 has normal, scientific, date calculation, multiple unit converters, equation graphing with customisable theme, zoomable scrollable live updating high quality, themeable graph.
Win 10 integrates with the Windows contacts in some way to let you share graphed equations with other people. Currency conversion pulls currencies and live rates from the internet.
Win 10 has Programmer mode which does base conversion, logic gates, bit shifting, bitwise number representation with click-to-toggle-bits for entry and viewing.
Win 3.1 calculator is a binary blob, Win 10 calculator is open source MIT licensed on GitHub https://github.com/Microsoft/calculator
And they do introduce performance improvements - e.g., downloading pre-existing indexes instead of having to index your entire JDK and Maven repo.
https://www.jetbrains.com/help/idea/shared-indexes.html#shar...
Disable extra plugins, do not hesitate to mark directories as 'excluded' if you don't need them to pop up in search (especially build directories), and be patient during the 5-10 minutes indexing when you switch to a new project (which should not happen often) is more than enough to get very good perfs.
I've heard of a vim extension/mod for VS Code but haven't had the time to dig into it.
Of course, if you don't use too many plugins, vim is also designed so you can run it remotely. I use this sometimes to have a long-time running vim session on a remote server, using tmux or screen to reattach when I log in.
And if you haven't tried it, use tmux.
It is the geeky tool that unlike vim/emacs you can learn in 60 seconds and immediately adds value. Whereas vim/emacs take longer to learn and get a payoff - I never managed to get to that part of the curve.
Add another 5 minutes to set up a tmux script for your development workflow!
The title should really be "My IDE is too heavy so I moved to Emacs for hobby projects".
It's hard for me to come up with examples where the emacs setup wouldn't already be done in a couple minutes or using grep and a writeable grep buffer.
While IDEs may require more resources, they usually utilize them better.
Emacs is fundamentally single-threaded and not great at async things. With most of the logic written in a very slow non-JIT friendly language with naive blocking GC. Rendering pipeline is also a mess. Underlying internal datastructures are also very naive (which is a good thing when you implement things in C).
Things are slowly changing. emacs now is a lot better than 5 years. So may be in 10 years it will really rival more modern competitors in terms of performance.
Having said all this, emacs universality and extensibility keep me with it.
Just a minor annoyance, really. It would be nice for emacs to improve on the async front, but synchronicity does have its benefits when interacting with humans. I sometimes find the lack of asynchronous behaviour annoying in emacs, but not very often despite using EXWM (so locking up emacs means locking up the window manager).
I can't be sure I didn't just make a typo, but this has happened much more often in Intellij than in vim proper, so I think there is something going on where IDEA has a hiccup and scrambles or eats some inputs.
And yes, autocompletion fires from many different keys, and if it misses the keys order, it will automplete into some completely different code.
Does anyone have any input?
Your response reminded me of an Intel project about regular expressions. I think it’s called hyperscan, but I’m not sure. It’s a regex engine (I think that’s the correct terminology) that makes dedicated use of very specific Intel instructions to reach incredible regex speeds on Intel processors. Would be cool if Emacs could make use of this tech when configured properly. I bet there are some internals that rely on regex.
> For example, querying your compiler for a list of methods that apply to the current object, or a list of functions that start with “Foo” are mostly moving to external processes using LSP as the communication protocol.
That's why we have lsp-bridge and lsp-mode emacs fork :) Both of which build some infrastructure to avoid doing communication work with lsp-mode work in main emacs thread. So, heavy emacs users are building some async machinery which wraps another already async and relatively lightweight protocol, because core emacs facilities can't keep up with it. Architecturally it is kind of insane.
I think, lsp-mode fork is doing the right thing (from practical POV; it goes against "emacs is just an elisp interpreter" ideology though) and hope it gets into core at some point. A better solution would have being having first class async and background threads support at the elisp level. Which would never happen due to elisp messiness.
https://github.com/emacs-lsp/emacs https://github.com/manateelazycat/lsp-bridge
If you want to contribute to the future (pun intended) of multithreaded Emacs, your best bet may be to make a library that adds the nice concurrency facilities that will help library authors move to a multithreaded model. An actor model, green threads, or supervision trees may be avenues worth pursuing.
A big blocker is probably the dynamic binding, but trying to "fix" that would break a lot, if not all, of the existing libraries.
It’s such a monumental task to hack on the basics of the text editing. I listened to a tts book; I think it was titled “The Art of the Text Editor” that delved a bit into some of the original philosophy of the text rendering etc. in Emacs. You might enjoy it If you ever need a boring book to read.
I really wish I had the capacity and capability to pursue this effort. I barely have the energy to be good at shitty DevOps and Terraform, writing basic Python and Node is so time consuming. I can do some Lisp, but only at the basic level of init.el and adapting a few configuration examples.
I do the good thing and donate to the FSF monthly but I wish I could donate directly to Emacs because I use it every day. Even better would be to sponsor the development of a concurrency library and port of major things like magit or org.
I've requested this whenever I've had the chance. I would be very happy to donate some cash to get core Emacs improved. Emacs has made a huge positive difference to my professional life for years. Unfortunately this is not made easy.
I think one of the issues last time I looked into it was that FSF couldn't have donations on a platform that was potentially tarnished by having e.g. non-free javascript running on it somewhere... All very correct and in tune with their mission I'm sure, and part of the reason why Emacs etc. has been so successful, but it would be nice if they were a bit more pragmatic occasionally.
The Emacs community has always got by through finding other ways to ensure responsiveness. It's true that each individual user shouldn't have to spend that much time on configuration (Doom Emacs and such distros help here), but still: people who find it slow must have misconfigured something, and on profiling, they'll find at most 1 or 2 features of their config that's eating all the CPU cycles. These won't actually be hard to fix, for a programmer, and threads wouldn't have helped matters, and at best only have hid the CPU-eater.
Even Emacs current threads library suffers from data races which is one of the reason I believe it has not seen much adoption.
(where suffers from data races is a link to Chris Wellons' post).
The idea now is, as Chris states:
There really needs to be a safe, high-level API with clean thread isolation. Perhaps this higher-level API will eventually build on top of the low-level threading API.
While you are right that for 99% of standard usage single-threaded code is entirely fine, not utilizing between half to 15/16ths of potential processing power is a bit of a shame, especially considering it means doing something like indexing an entire project (yes, we can use GNU Global) will require the user to just sit and wait.
I suppose if you still want that program to be written with Emacs Lisp, you could use async.el (https://github.com/jwiegley/emacs-async/) and there's finally an use-case for the threads: it'll be relatively safe to run those 16 threads only in the external Emacs-process.
https://blog.phundrak.com/emacs-29-what-can-we-expect/
It is still order of magnitude slower than JS. Dynamic binding, ability to redefine or advice any function and fundamentally cache-unfriendly core datastructures (cons-cells) and absence of JIT hotspot optimization do not help to catch up with competition :(
I still like Emacs. I prefer free software. I love Magit. But, the UI responsiveness is honestly frustrating when using LSP.
Do not use linum-mode anymore.
I can display buffers with hundreds of thousands of lines while showing the line numbers (Emacs 29 / native compilation / display-line-numbers-mode / CPU is an AMD 3700X with 32 GB of RAM) and Emacs is ultra responsive.
Why oh why couldn't they improve linenum-mode instead of introducing a new mode.
What about the manual?
https://www.gnu.org/software/emacs/manual/html_node/emacs/Di...
The issues you described are mostly totally solved by looking in the manual first rather than externally.
> Why oh why couldn't they improve linenum-mode instead of introducing a new mode.
The double-edged sword of being very backwards compatible.
In practice, you can get far with Emacs' process supervision to avoid blocking the command loop, but some things that are trivial to offload to a worker thread are next-to-impossible to avoid blocking in Emacs. One of those things is parsing megabytes of JSON from an LSP server into Lisp data structures, which is baked into the Emacs core and will block redisplay.
When it comes to memory, my point is precisely that we should count the language server in the total and not just the Emacs process. So, when some other IDE is using multiple GB of memory on my Rust project, we have to compare that to my Emacs + rust-analyzer memory usage because both of those processes are providing the features that other-IDE is providing.
However, Emacs is also still kind of laggy when using LSP, even though the actual LSP server lives in another process and communicates mostly asynchronously. My understanding is that there are still bottlenecks in Emacs that make this not truly async. But, even if my LSP server of choice is extremely slow, why should that affect my cursor movement or typing speed in my Emacs buffer? I can see why it would be technically difficult to make it NOT introduce some lag, but it shouldn't in principle.
I haven't used Visual Studio Code, but my understanding is that it is plenty responsive to typing and cursor movement, even while using rust-analyzer.
It moves the json rpc stuff to be async, and makes a real difference in terms of perceived performance.
I tried to switch to Emacs multiple times, but the lagginess in a non-trivial setup just kills me.
I always went back to Neovim.
Currently use vim, or things like gedit and kate that come w/ a DE. I would really like to learn to use emacs, but the last so called "beginner" tutorial I tried started with _learn a new lisp dialect so you can write emacs extensions_. Seriously.
Does anyone know where to find a tutorial that teaches you how to do things like open a file, type some stuff, and save the file?
Maybe show whitespace change highlighting modes and a few hotkeys if I want to get fancy... but like otherwise normal beginner stuff?
https://youtrack.jetbrains.com/issue/IDEA-270042/High-CPU-us...
Other than that, I agree with you. In addition to well-known performance issues and longstanding bugs, I'm also still waiting for features like full Wayland support that was promised by the end of 2020. I mean, I understand it's not on their highest priority, but why promise things you're not actively working on?
a) a lot of existing code that needs to be untangled (e.g. moving various tasks to not depend on indices);
b) figuring out how to avoid unnecessary re-indexing (e.g. the downoadable index caches for things like Java files);
c) having to define a migration path to spread out breaking changes to give plugins enough time to adapt.
IIUC, some of the performance work with the latest version is due to parallelizing the various background processes, which uses coroutines, so you could add "implementing language, library, and tooling support to Kotlin/Java" to that list.
For anything else (python, js, elixir) I use VSCode with a careful selection of plugins. It works very nice even on my Thinkpad T420.
I agree with the people that said that if you install a lot of plugins (lsp etc) on a bare bones editor it will feel very slow; I had exactly this experience using vim on Windows: Using it as a text editor with only a few plugins (fzf etc) was great but when I started using is more like an IDE the experience wasn't that good anymore resulting in choosing VSCode instead.
I find JetBrains IDEs to be significantly better at Python and JS/TS (they do have dedicated IDEs for them after all).
I wish Elixir support wasn't just one guy from Jetbrains working on it in spare time though...
Better that than the travesty they did to the intellij-hcl plugin, where they .. hired? in-housed? I don't even know what they did to that plugin except completely and utterly broke it and made updates to it go into this weird black hole
Extensions -> type "emacs" -> done
I really hate this articles that scream "look I'm so old school I use vim/emacs" while emacs is a single threaded nightmare that will work worse than any IDE if you will try to configure it to make it usable for actual every day work.
The complexity of the toolchain tends to sip into the result over time.
Conway's law.
It's also not recommended working on personal stuff with work's hardware and means, you risk losing your hobby projects to your company.
And during work time, you are supposed to work on things the company told you to do, not personal stuff. If you are planning to do extra hours for that, why should it matter where you do it?
Your comment probably seems non intuitive to many of us for all these reasons.
So, don't worry about the downvotes. They will understand someday.
And yes, people do things for fun, too, not just for money.
I shouldn't do what I like because what? Because bowsamic doesn't like it?
It's not 1920. The modern middle manager has more invested in his fantasy football league than his direct reports -- and by some magnitude. Grow up.
To add my anecdotal evidence: I have a relatively new Dell Core i7 laptop with "only" 16 GB of RAM, and while using IntelliJ IDEs "normally" (i.e. not while it's updating its cache), the CPU usage rarely goes above 5%. So the impression that you need top of the line hardware for running IntelliJ products that the blog post is giving is a bit exaggerated...
Disabling plugins helps a lot, though. On install you'll get a screen that let's you select tons of features that had me going "gimme gimme gimme" but in hindsight I've never used 90% of them. For example, Android support is a major plugin I've never used with Idea because Android Studio exists and seems to integrate much better. Disabling that cut down startup time by a noticeable amount when I last culled my install.
My experience with tricked out command line editors has been that they start out blazing fast but as you add more and more features (syntax highlighting, linting, etc.) they become slower than your average IDE. They're still responsive when they're not doing anything, but sometimes they just need a few seconds to think, breaking up my work flow.
Another issue that I've seen some people run into is that IntelliJ will index all your files. If you have some kind of process that slows down your computer when you're opening tons of tiny files (say, an antivirus program or a project stored in a hard drive) that can instantly kill your work flow. The only alternative seems to be to postpone loading all the files until you start searching (which VS Code seems to do) but then you're just moving the problem around, not really fixing it.
It's what I get for using a text editor for an IDE, I suppose. My experience with Jetbrains tools is that they're a lot more powerful than most of the competition at the cost of some minor input latency during heavy operations such as indexing.
I just wish that people write such posts six months after they have made the switch.
The author has only started. He only has stuff set up and checked speed. He hasn’t yet become as efficient as he was with JetBrains.
He might never become that, and after 20-30 days, he might throw in the towel and go back to JB.
_Being too bullish too soon_ is one of the serious maladies of the present personal-brand/influencer culture.
So it was my "IDE" between 1995 - 2005 when working on UNIX, muscle memory is still there and I still remember basic elisp stuff, yet I see no reason to abandon my IDE's, now that they are available everywhere that matters to me.
When it starts up, it loads all this metadata in memory. You feel the laptop being slow for a minute or so. After that, its mostly a good tool. Once in a while, it indexes something and grants you another coffee break.
I keep wondering, why XML? If you build this much metadata, wouldn't it make a lot more sense to store it in a database itself, and only load what you need from it? Say sqlite or h2 or something.
Another thing is, XML can be converted to objects and vice-versa relatively easily, so it is a neat serialization format in nature.
Also, parsing XML fast is a solved problem for the most part.
I have worked with relatively big XML files, and when done right, the path is not heavy, at all.
Edit: Oh, Considering this is IntelliJ and Java talks XML natively, this might also played a role in this being XML.
That part is pretty true. I didn't use XML in a case where I didn't need to read it completely and transform to objects, yet.
I'd not choose XML in these cases probably, if I ever encounter such a case.
Does anyone knows of vim or emacs plugins that do similar heavy lifting? Preferably decent at T-SQL
...
> As much as it hurts me to say this, as a fan of JetBrains and its tools, IntelliJ just seems to have become too heavy to run properly on a laptop that’s not at the very higher end of laptops in the early 2020’s.
IntelliJ does what I want, but only barely. The autocompletion gets it wrong as much as it gets it right and it is a performance hog.
I can deal with that.
The problem for me was JetBrains' privacy policy[0]. It is loosely-worded enough to forbid them practically nothing, and I find that especially appalling in a so-called "community edition".
So I began searching for alternatives. Emacs may serve for OP but I always forget how to exit it so I wanted something with a clickable "close" button in the top right.
I am getting a good initial impression from Codelite[1]. I'm sure Codelite doesn't do everything IntelliJ's IDEs do, but it has the functionality I use and it is a breath of fresh air after waiting for IDEA and the like to catch their breath during text editing.
[0] https://www.jetbrains.com/legal/docs/privacy/third-parties/
[1] https://codelite.org/
What, specifically? Because I can see they are bound by the GDPR and it seems clear to me:
> If you install on-premises products such as IDEs or .NET & Visual Studio Tools, these products are located on your hardware. JetBrains does not provide hosting for these products and does not have access to any of your data processed with these tools, unless you actively decide to share this data with JetBrains.
c'on! Last time I checked (2 seconds ago), Emacs' GUI has a "close" button in the top right. And a "File" menu at the top left with a "Quit" entry, that teaches you the shortcut (C-x C-c).
Emacs in the terminal (emacs -nw) doesn't have the top right button but still has the menu. We can't click it by default though. Use: F10, or M-x menu-bar-open, or M-x xterm-mouse-mode and click on it. https://www.gnu.org/software/emacs/manual/html_node/emacs/Te...
That's the cool part, you don't!
Jokes aside:
- Every emacs install i've ever done had the familiar X at the top right to close it. How did you install?
- Related to the joke, running emacs as a server is quite nice
Vim/Neovim are always fast. Even with 30+ plugins configured. I can run them on any hardware and they are blazing fast. Not to mention the superiority of modal editing if you are used to it. I have every feature I need (LSP/code completion/diagnostics/even debugging via DAP).
Pretty sure that I won't switch setup for a long time/ever again.
https://www.lunarvim.org/
https://nvchad.com/
However after some time you probably want to configure your own and only include what you truly need. For this a good solution is to just adapt https://github.com/LunarVim/nvim-basic-ide to your liking. This is made by the author(s) of LunarVim.
I have used JetBrains in the past and I never was a fan. It is very slow and lagy in many situations. If I'd go the "IDE" route vscode would be my choice.
What I think people don’t get is that it’s not just Vim. You can add hjkl to another editor and it doesn’t make a difference. The terminal is my IDE. I run vim within tmux side by side with a shell, and I’m way faster at grepping for something than IntelliJ is at indexing and searching. My editor never has a few-second lockup. I never depend on the IDE to build my code, so when I work on something there’s a functioning Makefile or equivalent and it’s inherently ready to build and test on CI.
I don’t care about Vim vs emacs. I’m sure emacs is great if you’ve invested in it like I have vim. But contrary to all the IDEs and editors I’ve been urged to switch to over the last ten years, vim is still kicking and I keep getting better with it. If I adopted the new hotness every few years that wouldn’t be the case. You can pry vim from my cold dead fingers.
That's actually the main thing, deep and wide integrated linting.
Almost everyone does autocompletion (up to a point).
Almost no one does linting as well as they do.
Quick experiment for you.
Take a big source code file you've worked on, preferably solo, so you won't have excuses :-p Not a "best case scenario" file you've cleaned up and polished. Be honest with yourself, something big and reasonably messy where the deadline was tight or the issue was complex.
Open the entire project and configure it in a Jetbrains product.
Open that specific file in the IDE.
My guess is that the top-right green checkmark won't be there.
You just can't hold all that stuff in your head at all times.
That's why we use computers and tools (such as advanced IDEs), to remind us of this stuff.
Anyway, in the rare case that you actually do all of that on your own, <<you>> are an outlier. 1%, 10%, for sure you're not lower than 50% of developers. The majority of developers need that help.
Definitely not saying anyone else should use Vim if they don't want to, just that Vim is part of my productivity superpower and I take offense to it when part of the onboarding experience is setting up an IDE and someone really pushes it on me.
The Jetbrains linters are proprietary, though they can integrate Open Source ones, and generally better and more thorough than Open Source ones. They're especially better for professional development where you use various frameworks.
> I take offense to it when part of the onboarding experience is setting up an IDE and someone really pushes it on me.
That's fine, but being a part of a team sometimes requires sacrifices. It's as true in football as it is in software engineering :-)
Plus I'm sure reasonable teams just leave you alone if you do your job well and your setup doesn't intrude on what everyone else is doing.
It's only fine if this provides something to the team which you could not provide otherwise and in my experience this is not the case usually.
Now I moved to Go, and that is not needed anymore. Most thing are already bultin or can easely be extended (like with golangci-lint). It's static typed with simple OO model which makes things a lot easier. Since then I've been working neovim and I don't feel I miss anythig from full-featured IDE.
That is what you should use. You can't run Intellij IDEs on CI to validate the pull request.
That said, I do appreciate the powerful code analysis provided by Jetbrains IDEs.
I still use IntelliJ for Java, but for everything else neovim is working well. I still have VSCode for a fall back.
Now people have to rediscover Emacs from 47 years ago.
For most of its history, Emacs has been the very definition of bloatware.
vanilla emacs/vim with default config are just editors, but they can be configured to have most if not all the functionnalities of an ide.
No, I don't need to freaking have a goddamn FTP and SSH client built into the tool that I so heavily rely on every day just because there is a use case for it in someone's brain that is orthogonal to the vast majority of its users'.
Also fuck the evil that is Codespaces.
Migrating over is easy too as you can import your shortcuts with "Sublime Text Keymap and Settings Importer"
All these together and you have a keyboard driven ultrafast IDElike experience.
I tried VSCode and went back to Atom -- it still works fine but expecting that won't last
Ideally I really need one where I can run bash sessions in tabs alongside code, I don't really use autocomplete and such -- but it needs to handle a lot of open large files with zero lag and instant search
Wouldn't it easily be solved if people were actually using decent desktop environment or take the time to configure it correctly?
I mean it is not complicated to move from ide to terminal if the desktop and shortcuts are well made.
What were your blockers to moving to VSCode? My remaining issue is to be able to css style any element of the UI like I could with Atom. There're plugins that let you monkey patch to get that feature, but updates to VSCode break them.
It's a kitchen sink even before you install any plugins, and yet all the useful functionality requires plugins.
All I want is a text editor that can quickly switch to another file, that doesn't make it annoying when the file it had open was changed, that only adds the input that I type to a file and nothing else.
Also easy integration with commandline tools (select text, pass that as stdin to a command, replace it with stdout, all done trivially without going through a billion menus and plugins), vertical selection and multi-cursor that doesn't suck, maybe a few other details, are things where it failed to deliver.
I understand these are some folks trying to keep Atom alive.
But now I use code-server, which is hosted on the same development server. So everything got a lot faster for me.
Why? It doesn't just load the file, but also analyze it, find flaws and put it into a bigger picture which assists the user. And you don't need a last gen for this. I work on a 10 year old machine quite fine with a rather heavy IDE-Setup. Just accept that a computer can be your partner, helping you to reach your goal, and that he needs his time for doing his work too.
To make a simple example: Have multiple functions defined at the top level of the file? Great! Independent parts!
Of course it could be, that in one function another is called, but does that have to affect highlighting? Immediately?
Furthermore we are fighting a strawman here: Who in their right mind opens a 100k line code file in an IDE? And who in their right mind creates such a disaster in the first place? This is not a realistic scenario we are talking about here.
Sure it doesn't see frequent updates... but so what? That might well be a strength since some kinds of changes can be low value & highly disorienting. The plug in eco-system isn't as broad as that for VSCode, but unsurprisingly there's more cruft there, too.
Ultimately your mileage will vary based on your preferences, but I'll stick with Sublime Text until there's something really more compelling.
Just wanted to say thank you for a fantastic text editor. It feels like a superpower when I show it to non-tech people
This. ST has been my best coding tool for the last few years. A keeper. Thank you!
It was a bug where selecting some text and using the key shortcut to multi select the next instance would select incorrect text for certain strings. It was a while ago so I don't remember the details, it may have been some combos of whitespace and non-alphanumeric characters.
It wasn't the only reason, but it was the final impetus to try some other solutions.
Hasn't been enough motivation to leave ST though
Emacs has all the features of VScode, plus more. And it keeps expanding by each day. A "fully featured" Emacs "IDE" is also just as laggy, sometimes even more, as any other "fully featured" IDE. Some Emacs configs even take tens of seconds to load! Mine however takes 1.5s, but that is because everything is lazily loaded. The first time I open a C++ file, it takes a couple seconds.
A really nice easy to use framework for getting productive in Emacs quickly is Doom[1]. You should give it a peak if you think Emacs is "low-level".
[1] https://github.com/doomemacs/doomemacs
Fleet is supposed to be this lightweight editor but unless it can beat sublime at startup, it's not.