Live data from Hacker News

Sunsetting Atom

github.blog

751–760 of 880 posts

Re: Sunsetting Atom

#751
post #690

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…

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?

OK you want motive. If you do accessibility with priority, you will get a whole new set of users who are always overlooked. A less competitive way to get easy money or user base depending on your product's model. ;)

I recently had a scare with my eyes. Freaked me out. I started looking at my developer tools completely differently. You are not out of the woods buddy. Anything can happen tomorrow. :)

Re: Sunsetting Atom

#752

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…

IMO the killer thing that VSCode has over all the other editors is the wealth of extensions and a certain degree of simplicity. What are your plans for Zed in terms of extensibility and are you aligning more towards making something beefy and full-featured like the IntelliJ offerings or something more "lightweight" like VSCode or Sublime?

Interesting. Will you have built-in LSP support for most popular languages then?

Re: Sunsetting Atom

#753

Earlier quoted context omitted.

I agree. Correct me if I'm wrong, but most projects started by some form of organization end up being dead after handing them off to the community. That is, unless they make their code from the ground up to be as most readable and modular as possible. I remember many projects made by Sun Microsystems that just died when Oracle took over, even if the code is still there.

The history of Zulip is one of my favorite counter-examples to this trend. They have seen great growth and success since spinning off from Dropbox! https://zulip.com/history/

I wouldn't really call Zulip a counter-example. It wasn't aband^H^H^H^H^H released to the community, it was spun off as a separate company. They offer paid products, have employees, an office in San Francisco, etc.

Re: Sunsetting Atom

#754

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…

Funny, this doesn't sound like a spiritual successor to Atom at all. What made people excited about Atom (compared to Sublime Text, which people switched from and was ~always faster) was the extensibility.

Sounds like this won't have that. It's only a successor in the sense that it's built by the same people and tackles some of its challenges.

Re: Sunsetting Atom

#755

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…

I'm not sure if this feedback is useful, but I have to say that a collaborative text editor doesn't feel like that big of a sell.

Pairing in VS Code over Zoom has gotten a lot better over the last year or two, to the point that I choose it for simplicity over more purpose-specific tools like VS Code Live Share (which is a bit slow/glitchy but fine, and overall "neat") or Tuple (which is great).

Would I pay money for "VSCode, but faster"? Absolutely. I'm waiting multiple seconds for keystrokes to apply sometimes and don't know why. But the extensions are what make it VS Code – if I just wanted "a faster text editor" I'd uninstall all my extensions and just keep using VS Code (it'd blaze), or switch to Sublime.

I'm excited to see more people working in this space, so I certainly wish you luck!

Re: Sunsetting Atom

#756

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…

"collaborative" "Rust" "code editor" "CRDTs" is very reminiscent of Xi Editor by @raphlinus which shared all of these traits. Xi was abandoned with the conclusion that CRDTs aren't suitable as a basis for text editing interactions, or at least that implementation wasn't. Is Zed related to Xi in history or as inspiration? Why are you confident that Zed will be able to overcome the issues that blocked Xi's advancement?

I've been talking to Nathan and think he has a good handle on the issues. One of the biggest mistakes in xi was an over-reliance on async and a loose coupling between the main logic and the UI surface. Zed isn't making those mistakes. I'm eager to see what the come up with and look forward to friendly competition in the open source Rust UI space when they release their toolkit.

Re: Sunsetting Atom

#757
post #78

Earlier quoted context omitted.

No it's perfectly reasonable. That open source software forms some part of a commons is not really a thing in practice. Open source software is ran by maintainers, those maintainers own the projects, and they do with the software what they deem fit. And even if it were, VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase, they're the same sort of project serving the same sort of mar…

> VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase It isn't true anymore then saying Slack is rewrite of Atom. While it is using electron, editor and IDE aren't from Atom.

Electron could probably be described as "a big chunk" of Atom's codebase. The rest of VS Code has a lot of similar functionality to Atom, so calling it "a rewrite" doesn't feel that far off (except insofar as it was redesigned as well, but that's sort of semantics)

Re: Sunsetting Atom

#758
post #701

Totally understandable, but the justification in the first paragraph of "Why are we doing this now?" seems a bit self-inflicted: • Atom has not had significant feature development for the past several years • (thus) Atom community involvement has declined significantly • (thus) we’ve decided to sunset Atom Feels a bit weird in that sequence to blame the community. Just say that YOU have abandoned the project since Mi…

I checked back regularly for years to look for signs of life in Atom. There weren't any. Last blog? 2019. None of the releases did anything interesting. I work in Vue.js and needed that toolchain to work well, it never did with Atom. So they're blaming the community for something they decided years ago and kept deciding every week when no resources were allocated. Also, Zed isn't filling the void Atom left. Rust is i…

> I would still like an alternative because I don't think Microsoft should have the whole market.

Asking genuinely, why not Sublime Text? (I haven't tried it or Atom in several years, but used both back in the day).

Re: Sunsetting Atom

#759

Earlier quoted context omitted.

Very much so. As the first Electron app we were so excited about people being able to do anything they imagined. It was cool but ended up really constraining us. This time we really want to drive our API based on the most important things people actually need to extend. We need to navigate the trade-offs more intelligently.

This is important, think about the whole Web. Too many ways of doing things and too much backwards compatibility needed for tools to develop further. I always cringed at languages like Perl and also Groovy where the pride of the language designers seemed to be that there are so many ways to do the same thing.

but Perl have backwards compatibility, developers keep perl1 source code can run on current version.

Re: Sunsetting Atom

#760
post #676

Earlier quoted context omitted.

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 bri…

I hear you, but atom and vscode are noticeably slower at interacting and searching even at those small file sizes. So we're in violent agreement here!
Post reply on HN