Live data from Hacker News

Atom was archived today

github.com

251–260 of 614 posts

Re: Atom was archived today

#251
post #220

Earlier quoted context omitted.

On the contrary, working in a professional environment, almost no one I know is using vim or Emacs seriously day to day for coding. We all use VSCode because that is a tool that just works for our team and company. Having a unified tool set works wonders for group productivity, no more messing around with some employees not having a certain package and others needing to customize their vim configs. No, everything sim…

My experience of VSCode _is_ messing around with my config, but giving up and going back to a more mature editor because I could never get it to do what I wanted. I suppose capitulation was also an option, but I dislike the characterisation of tooling as something other than ‘actual coding’.

That's very strange, when did you use it? And what config did you need? In our company there really isn't any config we mess around with, just download the language plug-ins and that's it. If someone wants to add more then that's fine but not required.

Re: Atom was archived today

#252
post #115

Earlier quoted context omitted.

"VSCode is the greatest productivity tool in the history of software engineering" in a world where vi and emacs exist seems like a bit of an exaggeration, and I'm not even a fan of either (VS Code is my daily driver; I like my GUI editors and I like them to behave like normal apps on the platform I'm running).

Vim and Emacs cannot compare to VSCode when it comes to productivity. With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment for that language ready to go. This is light years ahead of the traditional editors, and saves many hours of time. Not to mention that VSCode has countless other productivity boosters built in which…

VSCode's out-of-the-box configuration is better suited for the most common modern development contexts (probably?) and its customization, add-on and overall UIs are definitely more aligned with modern conventions, more readily accessible and more exploration-friendly.

But VSCode is also less responsive, more resource heavy and ultimately less flexible or extensible. Vim and emacs have more of a learning curve, and their configuration is more fiddly, but the biggest hurdle is probably that the interfaces they use for this predate modern GUI conventions. Notably the "search by keyword, click install, done" workflow for adding extensions is definitely standard behavior in emacs (and vim too, I assume).

Configuration fiddling aside - and that shouldn't be a daily activity - "Vim and Emacs cannot compare to VSCode when it comes to productivity" is a claim that does not hold up to scrutiny. In the hands of an expert user, emacs (and again, I assume vim too) is definitely more capable and productive than VSCode. I'm fairly confident this could be demonstrated objectively. They just _do more_ and can be made to do it _exactly the way you want_ them to. The learning curve for vi/vim and emacs represents an investment, but one that can pay off handsomely.

The topic of this thread is actually a perfect example of one of the major advantages of these "classic" editors. Atom - and countless editors that have come before - has been sunset. And it will eventually happen to VSCode too. Your Atom customization skills (and mine) are wasted. Now we need to pick up a new editor and climb a new learning curve. But vim or emacs mastery is a skill you'll literally be able to use for the rest of your career.

It's absolutely valid to decide that learning how to use these esoteric tools well is not worth the effort to you personally, but there _is_ a reason these tools have been around for nearly half a century.

Re: Atom was archived today

#254
post #75
post #32

Earlier quoted context omitted.

Atom predated the LSP and leaned heavily into customizations with all the plugins running inside the UI thread (more like a traditional web page and 3p scripts). At the time they viewed the extreme customization support as a feature, and there was a thriving ecosystem of folks making plugins. That architecture has a major flaw though. A default install was fast, but a real configuration with all the plugins ended up…

VSCode is one of the greatest pieces of engineering of our time. It's really only when you compare it with Atom that you realize how great it is. Atom was built by incredibly smart people, who had full control over the platform and several years of head start, and they were still out-engineered by the VSCode team at every turn. VSCode did almost everything right: The choice of TypeScript as the base language (with wh…

> VSCode is the greatest productivity tool in the history of software engineering

Surely that honor goes to compilers, right (take your pick which one is the greatest)?

Sure, VSCode starts faster than Visual Studio, and has better IDE features than (pre-lsp) Emacs, but all of that dwarfs compared to the productivity increase of not writing assembly.

Re: Atom was archived today

#255
post #115

Earlier quoted context omitted.

Vim and Emacs cannot compare to VSCode when it comes to productivity. With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment for that language ready to go. This is light years ahead of the traditional editors, and saves many hours of time. Not to mention that VSCode has countless other productivity boosters built in which…

>With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment Very minor feature. It is not usefull unless you are constantly hunting for new languages. >Not to mention that VSCode has countless other productivity boosters built in which would require plugin hunting or fiddling with configuration files for Vim and Emacs. This i…

> Very minor feature.

Moreover it is supported out-of-the-box in emacs: `M-x list-packages`.

I think `:packadd` or something may be the equivalent for vim.

Re: Atom was archived today

#256
Wrote some NES map editors using Atom at one point. Was kind of a pain. I didn't use it much after that.

I don't use VSCode but it just feels like this started an era of Electron-based everything that slowly consumes all of our machine's resources.

Re: Atom was archived today

#257
post #75

Earlier quoted context omitted.

VSCode is one of the greatest pieces of engineering of our time. It's really only when you compare it with Atom that you realize how great it is. Atom was built by incredibly smart people, who had full control over the platform and several years of head start, and they were still out-engineered by the VSCode team at every turn. VSCode did almost everything right: The choice of TypeScript as the base language (with wh…

> VSCode is one of the greatest pieces of engineering of our time. That must be one of the saddest things I read this month.

Yes, it’s not.

It’s just free.

What people mean when they say “I can’t believe how good this is” is:

“I can’t believe how good this is for something I got for free”

That’s not engineering excellence. It’s just engineering; being given away as a loss leader.

Vscode is good and well maintained, but that’s because a lot of money is being spent making it so.

Enjoy it; there’s no harm in taking money people are giving away. …just don’t presume they’re either a) doing it for love, or b) going to keep doing it indefinitely.

Re: Atom was archived today

#258

It might sound controversial, but for me Atom was almost a 1 to 1 Sublime copy with worse performance and quality. It was slow and ugly. It’s only quality was that it was 0$. It was the first editor I’ve seen to choke when opening 1M file (it even had a warning that it’s a too big file - lol). There simply was not enough RAM in the world for this memory hog. I’m not really sad to see it go. It was another free toy of…

Sublime Text is a fantastic editor. In my opinion it deserves more popularity.

Re: Atom was archived today

#259

Earlier quoted context omitted.

VSCode is good but as someone who’s been writing software for nearly 40 years, I really feel you’ve over doing the compliments by a long long way. Compilers, operating systems, browser engines (unfortunately) and reverse engineering proprietary hardware/firmware are all significantly harder challenges than writing an IDE. in fact there have been excellent IDEs around for decades before VSCode came along. Yes the indu…

VSCode isn't the most complex of projects or most widespread etc. But from perspective of engineering a large project is about making 100s of small and large choices. In hindsight, lot of them are wrong. Take any software WinNT, Linux, Atom, IntelliJ, Adobe* you can now with all the extra information available today can find some decisions that were wrong. With VSCode these wrong decisions are very few and minor comp…

Dunno, just getting VSCode to run and debug a project requires manually editing cryptic config files which is what almost any IDE does much better...

Re: Atom was archived today

#260
post #75
post #32

Earlier quoted context omitted.

Atom predated the LSP and leaned heavily into customizations with all the plugins running inside the UI thread (more like a traditional web page and 3p scripts). At the time they viewed the extreme customization support as a feature, and there was a thriving ecosystem of folks making plugins. That architecture has a major flaw though. A default install was fast, but a real configuration with all the plugins ended up…

VSCode is one of the greatest pieces of engineering of our time. It's really only when you compare it with Atom that you realize how great it is. Atom was built by incredibly smart people, who had full control over the platform and several years of head start, and they were still out-engineered by the VSCode team at every turn. VSCode did almost everything right: The choice of TypeScript as the base language (with wh…

> VSCode is the greatest productivity tool in the history of software engineering

Really?

Post reply on HN