Wow! End of an era!
Sunsetting Atom
451–460 of 880 posts
Re: Sunsetting Atom
#452Earlier quoted context omitted.
That's not my recollection, at least. I was more of an Atom fan than a Code fan in the middle of the last decade, mostly due to aesthetics, as shallow as that probably sounds -- but it felt like Code surpassed Atom in terms of community activity head-spinningly fast, like in its second year. I also think the sibling comment is right; TextMate never had the huge collection of plugins later editors did, but you can ver…
Same, but if you're staring at an editor all day it has to look good. Atom did and still looks way better than VScode. VScode looks like a Microsoft product. You can also customize Atom easier than VsCode. Why even build on web technologies if you don't let your users change things. For instance you have to have an extension to custom load CSS and it's kind of a hassle. Heck even Sublime has an easier interface to ch…
Maybe I just have horrendous taste, but I just get GitHub Theme Light and am done with it. Do you tend to be nitpicky around aesthetics?
Re: Sunsetting Atom
#453Earlier 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?
The bloat VSCode has over Atom kills it for me.
Atom was unbelievably slower than VSCode for any comparable set of capabilities. What do you mean bloated?
Re: Sunsetting Atom
#454“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.
"sunsetting" is better than corp-speak saying "handing it off to community maintenance" Especially, if there isn't a dedicated community to maintain it. I'll take honesty over corp-speak any day. That said we probably only get honesty, because they want us using vscode instead.
Corporate speak involves blatant ambiguity and kafkaesque messaging. "Sunsetting" has a very direct meaning for GitHub, whether it gets supported by the community is something else.
Re: Sunsetting Atom
#455Re: Sunsetting Atom
#456Earlier quoted context omitted.
Ooh, this is interesting. It sounds like you learned a lesson here. Could you say more about what prompted the change? I once talked with a Firefox engineer who felt like an initial urge for openness left them with a lot of API surface area that locked them into a lot of design choices. Was it something like that for you as well?
>I once talked with a Firefox engineer who felt like an initial urge for openness left them with a lot of API surface area that locked them into a lot of design choices. LOL, as if Firefox provided a stable API to extensions
I think that's the inherent catch-22 of having a big API. You end up in a situation where you can't change things for fear of breaking the API, but you end up also not being able to hold the API stable for fear of not being able to change things. So you end up stagnating and breaking things all at the same time.
Re: Sunsetting Atom
#457Founder 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…
All these new generation text editors are cool and all, but I feel they are mostly rehashing the UI of VSCode. VSCode is fast enough, and the perceived speed of text editors / typing only needs to be so fast.
Looking forward to innovations in UI. Cause otherwise, VIM is comparable if not better in performance than modern text editors.
Re: Sunsetting Atom
#458Founder 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…
Best of luck with Zed, Nathan! I've always been impressed with your brilliance, vision, hope, and positivity. Hope we can catch up again soon, until then keep changing the world for the better!
Re: Sunsetting Atom
#459Earlier quoted context omitted.
We're pure Rust and hopefully faster. But yeah, plenty of competition in the space!
I work on the linux kernel using CLion and the IDE is still fast. I would not be interested in a non-Java IDE for the performance.
Are you using 32-core / 100GB RAM monster machine? I do everything on my rather powerful laptop, but Jetbrains IDEs are just too much. I can't have more than one project open at time, which is limiting. I didn't try CLion, only IntelliJ for Scala and Rider for C#/F#, all on smallish projects and it will still take 3-6GB of memory :|
I'd be interested in even lighter than VSCode IDE ;)
Re: Sunsetting Atom
#460Earlier quoted context omitted.
Ooh, this is interesting. It sounds like you learned a lesson here. Could you say more about what prompted the change? I once talked with a Firefox engineer who felt like an initial urge for openness left them with a lot of API surface area that locked them into a lot of design choices. Was it something like that for you as well?
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 "private alpha", any hints on how we might jump aboard!? ;)
EDIT Nvm, I see this is our best option for now: https://zed.dev/waitlist