> I know how an IDE works. All an IDE really needs to do is (a) let you edit a text buffer, (b) parse your source files, and (c) build an understanding of your

> I know how an IDE works. All an IDE really needs to do is (a) let you edit a text buffer, (b) parse your source files, and (c) build an understanding of your code and provide you with intellisense. What's hard about that? Why is my IDE slow? ... > The IDE is very much unfinished. ... it freezes when opening super huge directories. So here's what's likely to happen: 1. To fix that freeze, you realize that you need to do file loading asynchronously in the background. 2. That in turn means you need to have your parsing/analysis run asynchronously so that it can analyze files as they come in. 3. But the UI that is reading analysis results is still running on the main thread. So now you need to add locking and other concurrency stuff everywhere. This takes a year of your life. At the end, your IDE is now twice as slow. 4. Also, the user still wants to be able to edit code while all this asynchrony is going on. (Otherwise, you'd just freeze like you were before.) So now your analysis engine needs to handle both concurrent reads and writes while also doing file IO. 5. At this point (especially with all that locking and other concurrency stuff), it's so complex that "re-analyze the entire program from scratch every time" is too slow. You need to be able to maintain a persistent analysis state and incrementally update as the user changes code or files get reloaded. You build a complex dependency graph system so that you can determine which analysis state must be invalidated when a line of code in one file is changed. This is another year of your life. 6. Now your analysis engine is so complex that the limiting factor for making your IDE better is developer productivity. It is incredibly hard to touch this giant ball of mutable concurrent incrementally updated state without breaking something and/or losing your sanity. 7. You eventually realize you need to architect it at a higher level. Instead of low-level threading and locking and carefully hand-authored incremental updating code (which few humans can maintain), you replace it all with a bunch of more coarse-grained persistent data structures. This takes a couple more years of your life. At the end, you get an analysis engine that you can maintain, which is good, because in the meantime, three new major versions of Go have come out and users asking you to support 17 other programming languages. But your new coarse-grained analysis engine is five times slower than the old ball of spaghetti... 8. A user files a bug saying that the IDE crashes when they try to open their 20-million line Go program. It turns out your implementation assumed you could always fit the full AST for every source file in memory. OK, time to start working on a compressed code representation.... 9. Meanwhile, another user files an innocuous little bug asking why the editor doesn't support full-width characters, right-to-left languages, or emoji. You open up your beautiful, 200-line hand-written fixed-width text renderer in one tab. Then you open the Unicode spec in the other and start reading about "extended grapheme clusters", "combining characters", etc. In a third, you start reading about OpenType "multi-colored glyphs"... I agree that IDEs could be faster than they are. There is a lot of cruft. But it's very hard to fix that by starting with OpenGL Notepad and hacking your way to IntelliJ one Git commit at a time without ever monotonically regressing perf. That's like trying to solve climate change by taking a tricycle and incrementally welding your way to a carbon-neutral container ship. Writing a real-time code analysis engine for large-scale programs is hard. It's a big complex piece of code. Comparing it to a text editor is like comparing Tetris to World of Warcraft because they're both "games". That being said, I completely applaud the author for making a go at it. It's hard, but not impossible, and history is written by people who had the courage to do hard things.