Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sunsetting Atom

github.blog

Post reply on HN
Print view View original

601–610 of 880 posts

Re: Sunsetting Atom

#601

Post by blagie »

theteapot wrote: post #555
folknor wrote: post #551

Earlier quoted context omitted.

Interesting! I just wanted to let you know my perspective, which is probably quite unique. I started using atom pre-1.0, a long, long time ago. I immediately jumped to vscode when I realised it existed. The reason is a bit weird; it's the find-in-files/project (c-s-F/Ctrl+Shift+F) sidebar search/replace feature. Compared to the Atom (and from what I can see in the youtube talk, zed has the same "problem") which opens…

> I code mostly in domain-specific, esoteric, private languages, no stdlib or docs, and no online resources to learn from. Jesus, who are you?

There are also a whole bunch of languages for:

- Describing levels in video games, which are primarily data with code mixed in

- Describing transformations of different sorts (e.g. the types of languages used in compilers for specifying a programming language parser, and then optimizations)

- Defining hardware (analogues to Spice, Verilog, and VHDL). Hardware can also include mechanical objects, as well more broadly, wetware (e.g. custom bacteria, a la Ginko Bioworks)

- Run on custom hardware (e.g. SIMD and MIMD platforms, similar to GPGPU)

- Are primarily mathematical (e.g. for describing control systems, neural network architectures, etc.)

... and so on.

Not all of this is a DOD/medical mess. A lot of DSLs are REALLY REALLY FUN.

Re: Sunsetting Atom

#603

Post by kylebarron »

amanwithnoplan wrote: post #369
kylebarron wrote: post #244

I personally found Atom + Hydrogen [0] to be the most productive interactive Python environment I've ever used. I really want to see VSCode adopt some way to run a Jupyter kernel for a Python file (with a notebook UI) and have rich results in line with the code (i.e. not a terminal output off to the right side of the screen). [0] https://github.com/nteract/hydrogen

VSCode already does that as of some versions ago. https://code.visualstudio.com/blogs/2021/11/08/custom-notebo... https://code.visualstudio.com/docs/datascience/jupyter-noteb...

oh I had a typo in my original comment. I meant *without* a notebook UI. i.e. I don't want to see a cell UI like a notebook. I want it to be just a normal Python file where the output shows up in line.

Re: Sunsetting Atom

#604

Post by nerdponx »

brundolf wrote: post #115

I held out for a year or so after VSCode was released. It felt scummy how MS had swooped in and tried to hijack this new category of editor that GitHub had invented (this was before they'd been acquired, I believe) But once I tried VSCode... man, there was no going back. It was infinitely more performant and cohesive. Atom (with IDE-like features installed) felt so sluggish by comparison. I think the main improvement…

> I held out for a year or so after VSCode was released. It felt scummy how MS had swooped in and tried to hijack this new category of editor that GitHub had invented (this was before they'd been acquired, I believe)

Depending on what you consider the "category" to be, Sublime Text (2) was well-established for years before Atom came out, with BBEdit and TextMate before it.

Not to mention Kate, Geany, and the various other "lightweight extensible code editors" that have been out there for years and years.

Re: Sunsetting Atom

#605

Post by aniforprez »

albertzeyer wrote: post #469

So I wonder a bit, VSCode has clearly won over Atom. But technically, as far as I know, they are both pretty similar. So where is the difference? Are these just small details which VSCode got better? Or are there bigger things? Or why else did VSCode actually won? I have used both in the past. VSCode seemed a bit snappier, which is an important aspect for an editor. But I'm not sure if this was really the case actual…

Performance and extensions being forced to be simpler due to a fast more restrictive API. VSCode was miles ahead in terms of performance and way snappier than Atom was and the extensions on Atom gave frequent troubles cause they had all sorts of weirdness to them

Re: Sunsetting Atom

#606

Post by serial_dev »

ClawsOnPaws wrote: post #561
nathansobo wrote: post #253

Founder of Atom here. We're building the spiritual successor to Atom over at https://zed.dev . We learned a lot with Atom and had a great time, but it always fell short of our vision. With Zed we're going to get it right. Written in Rust, custom native UI framework, engineered to be collaborative. Just starting our private alpha this week, so the timing of this announcement feels quite fitting. Here's a talk I gave l…

Hey, Please don't forget about accessibility. Getting this right from day 1 will make your life a lot easier in the long run. If I remember correctly, I was never able to use Atom with a screen reader. Hearing custom UI already makes me nervous and I'm pretty sure I won't be able to use Zed with a screen reader either. Blind developers exist. Please don't forget about us. It's one of the few areas where we can actual…

How do other editors/IDEs perform in terms of accessibility? What are your favorites?

Re: Sunsetting Atom

#607

Post by nerdponx »

deeptote wrote: post #198
tlhunter wrote: post #104

Even though Atom was much "lighter" than VS Code in terms of UI, VS Code had so much more development resources thrown at it that it was ultimately much speedier than Atom. IIRC, even Brackets was faster. I see people complaining about the death of Atom, but in the past few years there just hasn't been a use case where Atom was the best choice.

Seriously, who actually uses Atom anymore? Before VSCode was a thing, I used it but then I got into Vim, Neovim, and now VSCode with the Vim plugin.

Atom to me was always "toy version of Sublime Text for web dev hipsters".

Re: Sunsetting Atom

#608

Post by jjtheblunt »

nathansobo wrote: post #253

Founder of Atom here. We're building the spiritual successor to Atom over at https://zed.dev . We learned a lot with Atom and had a great time, but it always fell short of our vision. With Zed we're going to get it right. Written in Rust, custom native UI framework, engineered to be collaborative. Just starting our private alpha this week, so the timing of this announcement feels quite fitting. Here's a talk I gave l…

No post body was provided.

Re: Sunsetting Atom

#609

Post by galaxyLogic »

exyi wrote: post #455
GordonS wrote: post #439

Earlier quoted context omitted.

What would you say are planned to be the primary selling points over VSCode?

From the other parts of the thread: Performance, maybe better collaboration?

I think that's a worthy goal. I find it really bad that in this age of super-mega CPUs apps still feel not much faster than say 20 years ago. The reason I think is because like cities apps are built on top of other apps, like VSCode on top of Electron.

Secondly when you re-create from scratch you can keep the best features and drop the ones we've learned are not so useful.

Godspeed!

Re: Sunsetting Atom

#610

Post by skohan »

shp0ngle wrote: post #506
jakear wrote: post #467

Earlier quoted context omitted.

Minification helps the parser too, try running VS Code from sources and you’ll notice startup is significantly slower.

huh I would think there is no measurable difference there. However I honestly have no idea how much time does JS parser spends on what exactly. Are longer variable names and less tabs that big of a deal? It’s all in memory anyway, no… the lexer or tokenizer or whatever (…I never finished my compiler course…) just goes through that

My best guess is maybe faster hash-map lookups on variable names?
Post reply on HN