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

681–690 of 880 posts

Re: Sunsetting Atom

#681

Post by iamnbutler »

diziet wrote: post #676
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…

Will it be native Sublime Text fast? Not on electron? I tried using VScode and Atom. Both were noticeably slow compared to sublime text. I can do silly, bad practice things like open a 50 meg log file in sublime and search for simple regex in the editor. Electron based editors stall and potentially crash.

I may be biased, but at least sublime fast, hopefully much faster! Moving to Zed felt like going from a 30fps to 144fps.

You should be able to open stupidly big files and shouldn't experience much to any lag. Nathan has a demo he likes to give opening one one of those huge json files and searching, using multiple cursors, etc. It is pretty cool to watch.

Re: Sunsetting Atom

#682

Post by ghshephard »

diziet wrote: post #676
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…

Will it be native Sublime Text fast? Not on electron? I tried using VScode and Atom. Both were noticeably slow compared to sublime text. I can do silly, bad practice things like open a 50 meg log file in sublime and search for simple regex in the editor. Electron based editors stall and potentially crash.

50 Megabytes? That's tiny I would hope in 2022 that any text editor can handle a 50 megabyte file.

I routinely (like every day) open 500 megabyte files in SublimeText, and just checked to make sure that it can handle 1.5 Gigabyte files without much difficulty (it can).

Admittedly - once we get into the 5+ Gigabyte file size, startup times become annoying enough that I usually switch over to vim.

So, thank you for bringing this up as an important requirement for modern text editors - they should be able to open up multi-gigabyte text files without even breathing hard.

Re: Sunsetting Atom

#683

Post by [deleted] »

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…

[deleted]

Re: Sunsetting Atom

#684

Post by giancarlostoro »

serial_dev wrote: post #606
ClawsOnPaws wrote: post #561

Earlier quoted context omitted.

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?

I've only ever heard good things about Visual Studio in this area, not sure if other IDEs are comparable. I do know Eclipse has a specialized build for this purpose as well. I wonder if XCode is also decent in this regard. I think Notepad++ might be only other one from memory that I know of.

Re: Sunsetting Atom

#685

Post by kasabali »

adregan wrote: post #123
ilrwbwrkhv wrote: post #92

Earlier quoted context omitted.

I don't know why anyone would ever move away from Sublime Text in the first place.

Sublime Text came pretty close to dying during the Sublime Text 2 years. I recall development slowed down substantially (it was a solo dev, IIRC), and it being pretty surprising when Sublime Text 3 came out.

Sublime Text has never came close to dying.

It was only adderal driven developer crowd making mountain out of a mole because they felt uneasy their frigging text editor hadn't been updated every other week.

Re: Sunsetting Atom

#686

Post by LocalPCGuy »

ghshephard wrote: post #678
AtNightWeCode wrote: post #659

Earlier quoted context omitted.

"Mission-critical tools should be hyper-responsive." Did not seem to be important with the worlds slowest dev-tool ever, Atom. ;) "Real-time collaboration produces better software." At design level, ok. Programming is in most cases not a co-op operation. If it is, then you are probably creating solutions while writing code which is the best guarantee for bad solutions. “Conversations should happen close to code.” Agr…

I don't use Visual Studio, so I'm intrigued as to what VS can do in 10 minutes that takes 2+ hours in VSC?

One example could be scaffolding out a CRUD app and DB fairly quickly.

Even excluding scaffolding, VS can eliminate a lot of the boilerplate that takes time if you need to type it out yourself.

Not saying you can't setup VSC to do those kinds of things also, but VS is a tools included solution out of the box. (I say this as someone who hasn't touched VS in a few years now, but used it daily for a few years before that, and who generally enjoys using good/fast text editors.)

Re: Sunsetting Atom

#687

Post by TillE »

hbn wrote: post #655
seoaeu wrote: post #644

Earlier quoted context omitted.

The killer feature of VS Code for me is that when you open a source file for python, or C++, or whatever it pops up a dialogue: “would you like to install the extension for this file type?”. Click that and you’ve got working IDE features for that language with none of the hassle of tracking down which is the right extension, how do I keep my plugins up to date, which dependencies do I have to install first, etc.

In my experience, it works up to the point where it installs the extensions, and then it does a bunch of processing and still can't figure out how to run the project or what the code means anyway. Plus I now have a slew of new extensions installed, and I'm not sure which are new looking in my list of extensions. IntelliJ has a pretty damn good track record for me, when I import a project it indexes for a minute or so…

And then you spend an hour figuring out how to configure the extension, and it's still clunky.

I like VS Code just fine as a text editor, but as an IDE Visual Studio is so much better, even for CMake projects.

Re: Sunsetting Atom

#688

Post by hansonw »

keewee7 wrote: post #79

Really begs the question what Visual Studio Code did right and what Atom did wrong.

(Note: I worked on https://ide.atom.io and Facebook's Nuclide team).

On the topic of performance - one of the architecture decisions that VSCode nailed was the 'extension host' (https://code.visualstudio.com/api/advanced-topics/extension-...): all VSCode extensions are sandboxed in a child Node process, and can only communicate back with the main IDE process via the VSCode API. This has huge benefits for performance:

(1) extensions can never block editor startup. this was a huge problem for Atom as package loads were startup blocking and it wasn't uncommon to have multi-second startup times with lots of packages installed - especially due to the fact that JS packages typically repeat dependencies, resulting in tons of bloat. Also extension authors are rarely performance-conscious

(2) extension code can never block the core rendering thread, another huge problem in Atom - you'd often have stuttering/frame drops if extensions were doing blocking work on character or cursor changes, which was more often the case than not..

The tradeoff of course is that VSCode extensions are very limited in the set of UI customizations they can make but MS did a very good job of designing their APIs to be sufficiently extensible in this aspect (i.e. having APIs for extensions to hook into all core IDE features). Atom's extension ecosystem was much more fragmented resulting in dependency/versioning hell.

As a side note, another benefit of the extension host model is how it enables extensions to semi-magically work on remote filesystems (including inside WSL) without needing complete rewrites.

Re: Sunsetting Atom

#689

Post by smolder »

_puk wrote: post #621
nh2 wrote: post #489

Earlier quoted context omitted.

> Sadly, Sublime is sort of dead. Sublime has ongoing development on https://www.sublimetext.com/dev and the last major release (4) was just about a year ago.

I was under the impression that the "forced" upgrade to Sublime 4 caught quite a few out, and may have been a nail in the coffin. I'm still rocking SLT 3, and it's my go-to for large file handling or just as a simple scratchpad, but development (of SLT) feels like it moves at a snails pace.

I'm in the same boat. I bought ST3 and have avoided going to 4, as now it's just my scratch pad and .txt viewer, not really used for development.

Re: Sunsetting Atom

#690

Post by polote »

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…

It is normal to advocate for your needs but asking for it to be included from day 1 is weird. The same way you don't start a saas app with localization from day one.

I'm not blind so for sure I won't really care about accessibility but honest question why not use an ide developed for blind people instead of using the same as non blind people?

Post reply on HN