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

551–560 of 880 posts

Re: Sunsetting Atom

#551

Post by folknor »

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…

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 c-s-F results in the main window, vscode opens them in the sidebar and doesn't clutter the main view with it.

The reason this is powerful to me is that I code mostly in domain-specific, esoteric, private languages that have no API documentation, no stdlib or docs, and no online resources to learn from. So the only way to learn is by example, or talk to someone who knows. Learning by example is usually much faster than talking.

So what I do is any new project is just a subfolder in a workspace that contains all known code in the language and the way I find out how to do something is c-s-F.

When the results cover the main view, or even parts of it (which is also possible with atom), it's just way too intrusive. The sidebar file list is useless to me at this point - where the result comes from is irrelevant. So why not use that space?

Also of course the fact that vscodes cross-file search was blazingly fast was an upside as well (I believe they used ripgrep for that since the start?)

Another thing I want to mention is (and you highlight the keyword search in that youtube talk around 18:54) the power of the command palette search method that is available in vscode: first-letter-matching. I don't know what the proper name of it is, but essentially "ps" matches "pub struct" for example. Obviously it matches it with a lower score than something that starts with "ps", but it's very powerful for matching in the command palette.

Thanks for listening.

Re: Sunsetting Atom

#552

Post by Already__Taken »

nathansobo wrote: post #300
aniforprez wrote: post #277

Earlier quoted context omitted.

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?

We plan to make Zed extensible via WebAssembly, but we're taking a different approach than we did with Atom. Our goal is to make Zed fast, stable, and collaborative first, extensible second. We'll be taking a more conservative approach with our APIs to ensure we can preserve our core values even as users add extensions. Our goal is for Zed to have the lightweight and snappy vibe of Sublime with the power of a more fu…

IMO the leap from sublime to vscode was because the extensions made it so welcoming & bultin. I think the next leap from that is by-default sharing of those extensions and config. WASM might be able to do that coupled with security defining execution. We need a trusted mechanism to share what git-hooks promised without thinking about it. Like you said, collaborative.

If extensions lock down the files they will touch and the urls that can be visited I think sharing them becomes more palatable.

Re: Sunsetting Atom

#553

Post by jzzskijj »

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…

I have to assume no-one in the team saw Pulp Fiction (1994) when you ended up picking up the name "Zed"...?

Re: Sunsetting Atom

#554

Post by brundolf »

rimunroe wrote: post #293
likortera wrote: post #243

Earlier quoted context omitted.

I've tried too many times already to use the Jetbrains IDEs, because I know they're great, specially about the IntelliSense stuff, autocompletion, suggestions, etc. But I just can't. My fingers are just too used to vscode, and I can do everything I need to. I feel like vscode is better at everything, and faster, except for the IntelliSense stuff. But lately I've tried GitHub Copilot and that just compensates it soooo…

Does VS Code support more refactoring and code generation now? I last used it heavily over a year ago, and at the time it seemed like anything beyond moving files and renaming things wasn't really doable. Meanwhile, in JetBrains's software I can extract and inline variables and functions, change signatures, split things out into other files, and more. I think I tried a plugin or two which were supposed to handle thos…

It all depends on the language plugin. rust-analyzer can do a lot of this stuff, I haven't seen much of it for TypeScript (though you tend not to need it as much in more flexible languages), not sure about other languages

Re: Sunsetting Atom

#555

Post by theteapot »

folknor wrote: post #551
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…

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?

Re: Sunsetting Atom

#556

Post by slightwinder »

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…

> Written in Rust, custom native UI framework

Interesting. I think a major reason for VS Code's success is their usage of web-stack, which is stable, powerful and well documented, enabling easy access to higher customizations for anyone. It will be interesting to see how much a custom UI can emulate this without html&css.

Re: Sunsetting Atom

#557

Post by lifeplusplus »

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…

i hate vscode is written in electron, i always noticed the latency, it's good enough but it's annoying. atom was same but worse. what I also disliked about atom and sublimetext, is how you needed to install 20 extensions to get basic functionality and they weren't always compatible, with each other. Vscode approach of having most of basic functionality builtin but behind flags which can be disabled meant most people had good setup from the get go. Vscode to me was like jetbrains but faster and lighter. Although in some cases jetbrains was more robust.

If there is vscode that was written natively. I'd be so happy. Even if there is a new branch of vscode that is 6 months behind in features but is built in native it'd be huge for me.

Re: Sunsetting Atom

#558

Post by hbn »

gcau wrote: post #130

I still use Atom purely for its simple easy git UI (while coding in VSCode). VSCodes git UI, and all others I've seen, are a disaster in comparison. I want a simple, easy UI - in atom its exactly that. If I need more I'll just type it in the CLI. I wish there was something else I could use that's like this.

I've never used a better git UI than the one built into JetBrains' IDEs (though I always switch it from appearing in the sidebar to appearing in a popup window, like how it used to). They could honestly package it as a standalone app and it'd justify its own existence

The merge conflict resolver is so intuitive and easy to use. I have colleagues who come to me for fixing merge conflicts even though I'm pretty mediocre at git in general :p My secret is I do it in IntelliJ

Re: Sunsetting Atom

#560

Post by Beltalowda »

trasz wrote: post #434
Doctor_Fegg wrote: post #7

“Sunsetting” an open source project seems… unfitting? Hand it off to the community, look for new maintainers, donate it to the Apache Retirement Home for Veteran Projects, sure. But saying that you’ve decided to “sunset” or “archive” it, telling users to plan for their migration, seems counter to the notion that open source software forms part of a commons - something that Github, of all companies, should understand.

It's not an open source project - it never was, it's commercial, corporate project releasing code licensed as Open Source.

"It's not open source, it's code licensed as open source". Hmkay... I find it impressive how concisely you're contradicting yourself in that sentence.
Post reply on HN