Live data from Hacker News

Atom was archived today

github.com

481–490 of 614 posts

Re: Atom was archived today

#481

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…

Yeah, same. I have that disorder where I reflexively try new editors, and Atom lasted about 20 minutes on my computer.

My daily driver editors for the last 20 years, in rough order, were:

* BBEdit

* TextMate

* Sublime

* emacs

I still fire up Sublime, but the longer I use org the better I am at general editing in emacs. It's a gateway drug. ;)

Re: Atom was archived today

#482
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,

Emacs would like a word with you.

Re: Atom was archived today

#483
post #79

For those looking for a good substitute, I've switched to Sublime Text and so far I've gotten it to pretty much a near-perfect replica of the original. Kind of surprising to me how much of the Atom UI was built to mimic the Sublime interface. I also tried VSCode, but was never really quite able to get into the interface the same way. For a while I tried customizing the interface with plugins like CustomizeUI, but Mic…

> was never really quite able to get the [VS Code] interface the same way You're at least the 3rd person I've seen make that observation in this thread. I don't get how VS Code made this so hard, isn't it fundamentally built on a fork of Atom's core? The CSS and JS customization seemed more capable and accessible in Atom somehow. I've heard only good things about the Sublime Text UX for literally a decade or more, bu…

> isn't it fundamentally built on a fork of Atom's core?

No. AFAIK the only thing common to them is Electron.

Re: Atom was archived today

#484
post #343

Earlier quoted context omitted.

It is a generic interface which also helps with many capabilities, including proper refactoring, formatting, and the like. Since VSCode does so much through it, basically all nontrivial interaction with the code base can also be used in other editors. A far cry from the days of sublime text’s regex-based autocomplete

Except it only works for trivial languages.

Rust-analyzer works via the LSP, and I'd hardly call Rust "trivial".

Re: Atom was archived today

#485
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.

It is. It reminds me of that unhinged essay in praise of Hillary Clinton:

> Maybe she is more than a president. Maybe she is an idea, a world-historical heroine, light itself.

No criticism meant of either VSCode or Hillary Clinton, but sometimes fans take things a bit too far.

Re: Atom was archived today

#486
post #342

Earlier quoted context omitted.

The thing is it successfully had work put in so that it’s a standard. “They did a thing that basically no one succeeded in doing” is, imo, proof of something.

I don't think anyone tried to really make a standard, as far as I know. But even if they did, there's lots of reasons why some things take off and others don't: putting in the work as you mentioned, whether it's any good, marketing, state of other tooling and tech, zeitgeist at the time ("timing"), etc. Would something like Go have taken off 20 years ago? I'm not so sure, the zeitgeist at the time was very much in th…

> But you know, putting in the work to write down a specification isn't really a marvel of engineering. It's ... just putting in the work.

It's no marvel of engineering, but someone did put in the work, and others used it, more that can be said about many other things that might be "better engineered".

Re: Atom was archived today

#488

Earlier quoted context omitted.

If we're talking about professional tools i'm not sure if setting it up as fast as possible is the best productivity comparison. All good tools need getting to know them, and setting things up yourself (eg. in vim) means you also know how to fix any issues that pop up in the future. Installing a vscode plugin for playing around is great, but it doesn't automatically make you a professional and stable production envir…

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…

Sounds like junior web devs working on Javascript pull-in-the-whole-internet code bases. Not criticising your choice, it might be the best solution to your specific challenges; that just does not sound like the environment I work in. If somebody can't configure their own editor and its dependencies, I wouldn't trust them to handle application dependencies in the supply chain either.

Then again, I might pre-date the which editor to use and how to configure it era.

Re: Atom was archived today

#489
post #328
post #255

Earlier quoted context omitted.

> 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.

> Moreover it is supported out-of-the-box in emacs: `M-x list-packages`. Or just use the menu; click on "Options” → “Manage Emacs Packages”. No need to scare people with “M-x” weirdness right out of the gate when it isn’t necessary since the option is right there in the menu.

I think it actually helps to present M-x to new people as being the "command palette" for Emacs. A modern starting Emacs setup should have a vertical completion setup and fuzzy matching, so hitting M-x and a few keys gives you a list of matching commands with their documentation next to them.

Re: Atom was archived today

#490
post #229

Earlier quoted context omitted.

But with a crappy language.

again, like the JVM I am not particularly fond of Java (I know I am not alone :-D).

Java can perform well, and even with all the enterprizey bullshit, it still performs much better than your run of the mill, best practices follower javascript program.

Javascript actually can perform well, not nearly as well as java can, but it doesn't have to be as bad as what you see on most electron applications. But it's not trivial to make it so.

Post reply on HN