Hacker News Reader

Comment by Barrin92 | Hacker News Reader

I'm one of the people he talks about who moved from diehard Emacs use slowly to more and more VSCode use largely due to the better UI experience around debugging and integration of a lot of modern tools. His point about features not being used when they're complicated to reach despite people claiming that they'll use them is a true observation in particular. You always can set up a lot of those features in your unix-style environments, but you're just not as likely to use them if the experience is somewhat scuffed.

As a sidenote I wonder if he's ever used Pharo, it seems like the kind of thing he'd like.

View on HN

I tried VScode twice and despise it. Cold never get it to be much more useful than a text editor with syntax highlighting. Tried setting it up for java and even with fiddling and tweaking it didn't work nearly as well as the default eclipse setup regarding code navigation and maven integration. It felt just like trying to get vim to be modern and useful. Maybe possible, but a lot of effort when there is other solutions that work right out of the box. Second try was for PHP, and that was even more futile. For PHP it actually seems like jetbrains is the only one providing an ide that doesn't make you lose your mind with that language, so not necessarily a sign that VScode in particular is bad.

For C++ I never even tried it because I'm usually content with qt creator.

Qt creator is awesome for C++ development. It is so crazy fast, especially when compared to Visual Studio.

Java, C++, and C# have best in class IDEs. But for other languages, especially dynamic ones, VS Code is close or better than a dedicated IDE.

VSCode is based on Electron, a glorified hack/resource hog of Chromium than even Github largely abandoned. It maybe "great" and mildly "popular" here and there, but it's built on a foundation of mud. Build native apps that work and are performant.

With enough effort and care, a frictionless experience can be made with a TUI should some "Jetbrains" come along and try to make a commercial product out of it.

This is the most "just use rsync instead of Dropbox" HN-style argument I've ever heard.

It's sufficiently comical to be satire

Yet I’m seriously considering moving away from Emacs solely because it does not boot instantly. Sure I could set up an Emacs server and all that, but come on: it’s a text editor. It should not take more than 200 milliseconds to boot on a modern machine.

If I care about that, I’ll probably care about Electron using hundreds of megabytes of RAM I shouldn’t even have to buy in the first place. It’s thinking like this that make people say sad things like "16GB of RAM is a bit tight nowadays, maybe you should go up to 32".

(Edit: to people who think buying a bit more RAM is no big deal: remember that our resources are finite, that computers are one of the most polluting industries out there, and the climate clock is ticking.)

I've done some tests some time ago, and Sublime Text, which is a native app, also takes a lot of memory. Plugins also do take lots of memory.

JetBrain's IDEs are extremely slow and memory intensive - well beyond VSC and ST - and yet, complaints are always directed at VSC.

I like to be able to edit new text files instantly, and the simple, pragmatic solution, is to keep an editor always open in the background.

I understand your point, but I can’t say I relate at all.

I start my code editor maybe once or twice a day, so the launch speed does not even register

RAM and computers in general are so cheap that I just max out every laptop configuration I buy. If you’re a programmer and will use a machine for work spending $3-4k every couple years should not be a problem, we’re paid very well and should therefore use the best tools we can find.

> I start my code editor maybe once or twice a day

I start my main editor (with the shortcuts I like and all) every time I write (or edit) a commit message. And back when I used Mutt, every time I wrote an email as well. (Now I’m using Thunderbird, but I did like the ability to use my preferred text editor everywhere.)

RAM is cheap at the individual level. But if the entire world needs to go from 16GB to 32GB or whatever, the sheer volume of the resulting electronic waste does not exactly increase my faith in humanity.

Have you tried Magit in Emacs? It's an embedded git client with a very smooth workflow. No need to open and close Emacs just to edit the commit message. Once I got really used to Magit, it's definitely my favorite way to interact with git.

Some valuable advice I got about Emacs after switching from Vim is that it's not really a text editor, it's more like an operating system. You shouldn't need to reboot the OS between saving a file and commiting it. I typically only start Emacs once, then do everything from inside it. That being said, it's a very different workflow from Vim or VSCode, and not everyone's favorite way to work.

I even got it setup so I open multiple projects in the same single instance, and slightly change the background color based on what root directory a file is in. This way I don't get turned around when working in both a client and server, or producer and consumer.

Great to about the bg colors

Please describe how you achieved the color config.

Here's a write-up!

http://deliberate-software.com/emacs-project-tip/

Awesome, thanks!

In JetBrains (and VSCode) you can write the commit messages in them directly, so no need to open another instance of the editor.

Just for reference, start emacs once, run M-x server-start and set your global git editor to emacsclient -t and you end up with an instant in terminal emacs editor for git, that will also leverage magit when necessary.

you could start the server automatically using `-a ""`.

I've configured $EDITOR to start `emacsclient "$@" -a ""` with necessary arguments (I get emacs frame instantly when necessary).

https://stackoverflow.com/questions/4458800/how-to-use-one-i...

That's an interesting counter argument. I would think that for the target audience on HN, rsync would absolutely be preferable to Dropbox. We are developers, not regular consumers. Same would apply to IDE's and editors.

I'm thinking "use rsync instead of github" myself lol

Seems more to me like saying "someone should make an rsync that's more like Dropbox".

Mildly "popular"? Which editor is more popular than VSCode?

Notepad++?

The Windows only text editor is more popular than VSCode?

By number of installs, maybe vim :)

If we go by this page: https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...

Then it has to be Windows Notepad. Android does not have a default text editor, if it did then I'd agree.

Maybe there is an editor out there for you that was developed in pure machine-code.

I agree that electron apps are unnecessarily wasteful but if there’s something important enough to deserve the resources is a code editor.

The underlying problem with Electron is that browsers are also massive resource hogs and I don’t see people switching to elinks anytime soon.

Maybe I’m stuck in a cycle of consumerism - accepting slower software and buying faster hardware - but I value convenience a lot and in the grand scheme of things vscode using up like $5 worth of RAM is not enough to look for alternatives.

Why should I prefer a strict grid of characters based on technology from more than half a century ago to a GUI for something with the functionality of a tool such as VSCode or Sublime Text?

«it lists different values that each tool prioritizes, and how "Core values are self-reinforcing. They attract like-minded people, who will then defend them."» https://news.ycombinator.com/item?id=29159433

It is useful in corporate setting when you have to edit files over ssh on some random machine and you already have terminal open. VS code has remote option but you have to set it up and navigate again etc

> "Technology from more than half a century ago"

I think you are missing out the part where it's technology developed continuously for almost half a century.

VSCode is very nice, but I quickly become frustrated by it's lag in comparison.

It does beats the pants of every other GUI IDE out there, with JetBrains IDEs coming a significant second place.

But Vim or Emacs with LSP are extremely capable IDEs and have unmatched speed compared to any GUI IDE you can name.

> But Vim or Emacs with LSP are extremely capable IDEs and have unmatched speed compared to any GUI IDE you can name.

I do not doubt that they are. I use Emacs with a simple config as the default editor to open files with, but I do not know elisp to set up something more feature-rich, and have not felt the need to yet, but I would like to try some day. It is a truly unique piece of software with lots of love put into it, and it is also GPL which I like. The problem is just that the defaults are painful and I want to know exactly what my elisp is doing, and this would take some work. Yes I know that Spacemacs and Doom Emacs exist.

But my comment (the phrasing could be clearer) was about the choice of TUI vs GUI if one was to start creating a new IDE today, in response to the parent comment:

> With enough effort and care, a frictionless experience can be made with a TUI should some "Jetbrains" come along and try to make a commercial product out of it.

In such a case my preference would be to have a decoupled architecture which would allow for both. You can make such nice things with today's computing power and graphics cards, that it would be a shame to not take advantage of it. And the performance can be stellar. We are talking TFLOPS nowadays.

>Build native apps that work and are performant.

The ‘native’ there is redundant. The only thing that matters is if VSCode works well enough and is performant enough to be a viable option.

Often native apps will win on the ‘works well enough’ criteria, due to superior OS integration and familiarity, but that isn’t a given. If you use multiple platforms then having a solid cross platform option also has advantages in that area.

> It maybe "great" and mildly "popular" here and there

VS Code is not just mildly popular, it's significantly more than twice as popular as any text editor has ever been in the modern era.

Source, it's currently used by 74% of programmers (https://survey.stackoverflow.co/2022/#technology-most-popula...), the next highest text editor, since the survey started in 2015, was Sublime Text in its prime (2016) at 31%.

It's fair to call VS Code's popularity unprecedented and historic. And it's already being used to shape the future of the industry. E.g., we're watching the decline of local development right now (outside of specialized use cases) largely through VS Code's support for remote development features.

This is most likely just beginning of how VS Code will leverage its position to shape the future of programming.

Ironically the main architect is Eric Gamma from Eclipse fame.

> it's currently used by 74% of programmers

74% of the respondents to the latest Stack Overflow survey, you mean.

Github didn't abandon Electron. Github created Electron for their editor called Atom. Microsoft later used Electron for VS Code. Microsoft bought Github. Github is sunsetting Atom (not Electron) to focus on VS Code.

https://github.blog/2022-06-08-sunsetting-atom/

It will be interesting to see if Microsoft's Maui effort will be able to compete with Electron using a somewhat more native approach. I suspect that it will not.

> I suspect that it will not.

I agree. The reason Electron got popular is because front end devs can quickly build a desktop app for use cases where a web app will not work.

And I say that as a web dev who has worked on probably a dozen apps with Electron. Mostly internal tools, but also stuff in production for end users.

For the end user projects we ended up replacing Electron with native apps using the native web view. Each app had a tiny native layer for stuff like downloading files, etc. I don't remember the exact numbers but our macOS app went from +100MB to about 5MB download. Memory usage was also great reduced. The macOS app barely used something like 15MB of RAM IIRC. That was in 2018. Today there are projects that already do this.

I think Maui will rather compete with Flutter and QT, not Electron.

It can via Blazor and WebWidgets, however I see that as a waste of development resources from the Blazor team.

For that Electron users would need to learn C#...

and yet millions of people use it every day just fine. It's not any more of a resource hog than emacs when you load up enough lsp's and add ons to make it useful and modern.

lol you probably never wrote a live of code in your proffesional life xD i've used Idea and it's shit and slow as fuck. VSCode works fast even on a laptop, with intellisense scanning code in background. Noob.

I've used IDEs, but just keep ending up using vim. With fzf, ctags, clangd and YouCompleteMe, it's a very productive tool for C++. The two things I really miss from Visual Studio are the easy project setup - writing cmake by hand isn't very fun and debugging why it isn't generating what you want is a pain ; and the great visual debugger - nothing I have tried on Linux is as comfortable as GDB's TUI, which isn't very comfortable to begin with, though the capabilities unlocked by the python bindings are unmatched. I've used GDB's python features to great effect to continually monitor the program and stop when it reaches the invalid state I'm interested in, while logging back traces of interesting points.

You should check out some of the new plugins that use the LSP - it's the same thing used by VS Code but available to any editor. Conqueror of Completion (Coc) is what I use and is very popular. It's even better than YCM

Same here, sort of. I've been using like 30 IDEs throughout my life, and chose emacs over vim during the period I was trying to stay within the terminal, but VSCode is the best IDE I've ever used period.

Have you tried IntelliJ products?

I have, and previous to that I was a big fan of Komodo IDE. One weird feature that I love from both VSCode and Komodo is the ability to open a folder as a project, no need for an actual project file or other IDE specific handling of it that older style IDEs always seemed to a require. The feature set of the IntelliJ products are quite excellent of course, but for whatever reason my need for some weird IDE-editor hybrid where the filesystem is what matters, not the project, always meant I bounced off them.

I regularly open folders as projects and the intellij (pycharm in my case) IDE creates it as a project without hassle. Just add a bit of a script to cleanup any ide project cruft it creates and I'd say you're mostly there. Compared to all I get from a real ide, VSCode is like a stone age dinosaur.

Sounds horrible. Just let me open a folder without it being a project or having to use a script to clean up stuff (wtf?).

I use an IntelliJ IDE and open folders all the time and it's never created any cruft to clean up. I think that only shows up if you start making project configurations (like file watchers to run preprocessors for web languages)

It still makes a .idea folder to add to .gitignore or clean up, just as .vscode makes a .vscode folder.

I don't see this as a lot different than MacOS spraying .DS_STORE files everywhere. It's not a big deal to add to .gitignore, but it does leave a fingerprint. It's just that tries to determine reasonable defaults if the path doesn't exist instead of Netbeans/Eclipse/whatever forcing you to pick them with a wizard if you want any of the "real" features to work.

VS Code creates a project though: .vscode folder.

Only if you make workspace-specific settings changes.

or be forced to bend to their idea of what a project is and which build tools I need to be using, I concur 100%.

Yeah, half of my coworkers used to be on CLion (for Rust). TBH I couldn't get past the fact that it reminds me of Java IDEs with too many things going on. What's better compared to VSCode?

VSCode is very, very bare bones compared to what JetBrains can offer in terms of refactoring, debugging, and code analysis (for major languages).

It's hard to start at anything specific :)

For Rust I found CLion to have no improvement over VS Code.

Not for Rust tho. VSCode+Rust Analyzer offers an amazing experience and I found it to be on-par if not better than IntelliJ/Clion with a much more responsive editing, startup times and task customization.

Considering that JetBrains doesn't use rust-analyzer I have a hard time imagining that it's better, more that it's worse :o

Absolutely, and I wonder how people who are not professional in both IDEs can compare. Typically VSCode + plugins + some additional software from old time like BeyondCompare etc. poorly make up Intellij's core functionality.

I haven't seen a single person who seriously used both and went back.

Search, VCS, keymapping, defaults, heuristics, refactoring wide of use, AI-based autocompletion - there's simply no real adversary.

Last time I was blasted when copying an old DB to a one in a new DB it correctly guessed the renamed columns based partly on type and size, partly on column names.

Also I love its suggestions so much that when learning a new language I always look at Jetbrains' respective autosuggestions - simply because it makes me a better programmer, faster.

Yes me too. I started with basic and then up through Microsoft products, swore off them for emacs for years and am now on vs code cause it works so damn well. That in itself says how well it works.

30 IDEs seems like a lot. Could you share why have you switched between so many? Could you list several specific points that make VSCode preferable over emacs.

I guess I’ve been programming since I was very young, so I went through a lot of horrible things like frontpage, dreamweaver, notepad++, and then a number of them per language (phpstorm, and other php IDEs, java IDEs, etc.)

The biggest selling point for me for vscode is good defaults (I like vanilla configurations to get started fast on new machines) and discoverability. I want to be able to install 10 plugins and try all of them in a few minutes, and learn shortcuts as I use the plugin (with emacs each extension is an investment)

Agreed, on approachable defaults for VSCode.

I found use-package, try elisp packages make it easy to try new packages in emacs.

https://github.com/jwiegley/use-package

https://github.com/larstvei/Try

I ended up with the best of both worlds (subjective of course!).

I use VSCode with a Vim plugin. I get all the best keystrokes from Vim, and the GUI of VSCode.

For me, going to Vim would be worse, and going to plain VSCode would be worse.

except macros doesnt work! and the multiline editing from vs code doesnt work anymore.

unless you got both to work?

They both work fine for me most of the time.

There are edge cases but I can’t think of a specific right now. When I run into one, which isn’t that often anymore, I’ll open vscode’s terminal panel and do a quick edit in nvim there.

For me I don't use macro's that much. I remeber they worked fine in the Visual Studio plugin, but not sure VSCode. If I really need it for a file, I can always quickly open gvim itself. If you use it in your daily workflow, then it might be an issue indeed. But I don't see a reason why a plugin couldn't offer that (like the Visual Studio plugin).

Vim multiline editing works fine :). Not sure what the VSCode offers thoug (maybe I'm missing out)

I went the other way, as soon as VSCode-like language server protocol was available for neovim I dropped VSCode. Now I have the same speed with modern features too. In the end it's what's best for you that counts, having quality options helps a lot.

Do you have debugging setup in Vim? (If so, I'd love to hear what that looks like!)

> In the end it's what's best for you that counts, having quality options helps a lot

I agree. I just can't stand the git CLI, and love the GitGraph plugin in VSCode. But like you say everyone has their preferences.

VS Code with a vim plugin is in the uncanny valley of text editors. It doesn't work quite right and a lot of functionality is missing. It's enough that there's more frustration and less productivity for no advantage.

The majority of my movements are moving around files and making minor edits that the vim plugin supports well. It saves me from reaching for the mouse in many case, and that's the entire goal for me.

Works fine for me. Can you give an example?

One thing I have issues with is autocomplete and using . to repeat the last edit (which includes the autocomplete). Other than that, all fine.

Edit: all the vim commands give me a huge advantage on productivity when editing. All the GUI with plugins gives me a huge advantage on project navigation. Would love to see anyone do better using either one or the other.

Try the vscode-neovim[1] plugin instead of the more popular vscode-vim plugin. It runs an actual neovim instance in the background and works so much better than vscode-vim, which I also found was "not quite right" and very laggy. It really is excellent, pretty seamless and can't recommend it enough.

1: https://marketplace.visualstudio.com/items?itemName=asvetlia...

I found myself using VSCode instead of Emacs when browsing a lot of files. Just recently I added treemacs to my Emacs setup so my use of VSCode is much reduced. I also took the small effort to setup GitHub Copilot to work with Emacs - for some types of work, Copilot is a real time saver for Common Lisp and Python work.

I would also like his take on Pharo, which I like and many years ago released an open source NLP library for Pharo.

Linus Torvalds likes the fact Kernel debugging is not user friendly so that it does not detract from good programming practice, making sure you really understand your code and what it should do before having to resort to a debugger.

https://lkml.org/lkml/2000/9/6/65

Yes I also thought about that. Two programming gurus on opposite sides of a spectrum. I find it refreshing.

Anyone who says a tool is better when it’s shittier is just insane or has a huge ego to protect

That note always struck me as pride in self flagellation. Having been around many talented kernel developers, most are perfectly happy with a debugger or any other tool they can use to debug something.

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

— Brian Kernighan

That doesn't really refute the point that Carmack made. Namely that a lot of the supposed inherent difficulty in the endeavour of debugging is actually incidental from a general cultural attachment to crap old tooling.

And I believe the point of Kernighan, as well as Torvalds, is that the difficulty of debugging serves as a bulwark against over-complicated code.

So that's why ed(1) is the standard text editor. Anything more usable is a dangerous extravagance! :)

Sounds like Brian has never used a good debugger

UNIX has never been the place of cool graphical debugging anyway.

> pride in

Not really: the linked text shows it is a costly strategy to avoid later «self flagellation»: it is meant to avoid the practice of mindless coding - of overly fast feature insertion, blowing amounts of low quality code to maintain. Torvalds: «I'd rather not work with people who aren't careful».

Also: «I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger ... that mindset where you know how it behaves, and then you fix it from there. [...] It's that you have to look at the level _above_ sources. At the meaning of things. Without a debugger, you basically have to go the next step: understand what the program does. Not just that particular line».

Implicit in that argument is that these kernel developers are writing low quality code / coding mindlessly. That’s a bold statement to make when you don’t know who I’m talking about.

At no point has anyone suggested using the debugger in lieu of understanding what the program does and that’s a pure strawman. Understanding is step 0. Once you’ve done that piece, a debugger levels up your game. Same with other tools like profilers, printf debugging, EBPF debugging, etc. Hell, even simple things like executing the code in the first place / running tests / gathering metrics is a debugging tool. It’s rare that someone stares at a difficult bug until they see the matrix. It usually involves iteration cycles of some kind to test out different hypothesis / collect data and a debugger is one tool to speed up those iteration cycles.

There was a story on HN a while back about how one of the inventors of Ethernet had to hook up oscilloscopes to figure out what the electrical signal was doing to figure out why CSMA wasn’t working properly. An oscilloscope is an analog debugger and you can’t tell me that the inventor of Ethernet didn’t understand Ethernet or that the oscilloscope hampered that in any way, especially since the bug turned out to be very nuanced with a chip generating a spike switching modes.

As the cheerful used to say: "«You» who"?

That is not implicit: it seems explicit and literal. Apparently, Torvalds must have had different experiences - and evidently within a strongly different framework: it looks like the project manager in a drastic effort to propagate the will about what is part of the project and what is not.

Don't both perspectives make sense?

If you are working on a relatively small or modular codebase for a long period of time Torvalds perspective makes sense, since the codebase will also benefit from that kind of introspection (ok Linux is not exactly small but excluding drivers is on the order of ~100k AFAIK, which is small relative to the time it's been active); id games are on the order of millions of lines of code (according to Carmack) and while the different engine generations are related they still draw a line under each one after a certain point and move on so they are also very time limited.

I enjoy playing computer in my head in fine detail on small code and find a lot of joy in small code. But I can also respect that on a large and unwieldy enough code base where it's necessary, it's going to make more sense to lean on a debugger and other tools more often.

There’s an important reason to keep up these computer-in-your-head skills: you don’t have an interactive debugger in production, or on customer devices. If you can’t reproduce the problem, then all you have is code and (hopefully!) enough logs to figure out what’s going on and make a fix.

Yes, he also worked his entire life on his own codebase. Reality for most programmers is not like that.

Nokia's Symbian OS was notoriously hard to debug, too. Half-baked emulators and the real device debugging was even worse.

I wonder to what degree this contributed to the eventual downfall of the platform. The learning curve was so steep and the IDE and tools placed so many mines under your feet so relentlessly that it must have driven some talent away.

(An example: you closed the emulator and it left over some running background processes that you had to fish out and kill in the Windows process manager. If you forgot to do that, you could restart the emulator, but breakpoints would stop working. But if you mistakenly killed another important background process, the restarted emulator would freeze and you had to restart the entire Windows.)

On the contrary, I just love working with JetBrains IDEs. The debugging functionality is so great that I feel no one is trying (deliberately or out of neglect) to waste my time. Given that I am 15 years older than I was in the Nokia days, time has become a more valuable resource for me.

That was not the fault of the OS though, but rather embedded dev in general. Techview (the emulator) allowed you to test your code to a point, but because x86 CPUs were more forgiving than ARM ones you still had to test your code on ARM reference boards (H2 and H4). There were only a handful of Lauterbachs floating around since they were so expensive. Only one team got to see the actual phones being developed, and that part of the building was off-limits to everyone else.

We went through several IDEs, Visual Studio, CodeWarrior and finally Carbide.

I’m not saying the OS itself wasn’t complicated though.

It's all well and fine if all that you see is what will run. These days so many frameworks and layers are below and on top of your code that it's hard to know how your (relatively) simple code will behave at runtime. We've become on some level config and package install warriors.

that works for him, and he is intimately familiar with his software, also he's a programming savant. I find as a consultant I often get dropped into poorly documented code to fix it and a good shell environment and IDE/debugger are invaluable especially for spaghetti python code with references that are nonobvious until you can hit a breakpoint and decipher where the hell an object is coming from.

I have a similar experience, I started to use Emacs with my first Linux installation way back in the late 90s together with pico (later nano for fast editing). A few years ago i came to know about sublime text and I was astonished how much can be done with it and how quick it was compared to Emacs. Sure it does not contain all the goodies Emacs has but i after getting sublime text i realized how much time i saved and focusing on code. Recently i stop bothering and moved to VSCODE and its pretty damn good.

I miss sometimes Emacs but i prefer to use VSCODE nowadays as its a much modern environment and brings me directly to the point of comfort. I also tried Neovim but i was not convinced to replace VSCODE, i mostly use it on the console for quick and dirty editing.

I'm also one of those people. I learned both Vim and then Emacs + evil-mode, used them for a decade, and then one day I changed computers, couldn't be bothered to set up .vim/.emacs.d and stopped using them except for Vim for topical config edits.

Now I like to have a GUI that has things like a right-click menu instead of having to rely on maintaining muscle memory for everything.

Of course, another part of that, I think, is becoming older. Mastering some aspect of the computer or software like Vim just isn't interesting to me like it used to be.

It's just easier, it's not as powerful but it is "good enough" and much less steep learning curve.

Reply on news.ycombinator.com