Does anyone know the current status of https://zed.dev/ , the editor by former Atom devs?
We just started a private alpha this week! Lots of news and more public facing information coming soon.
Sunsetting Atom
271–280 of 880 posts
Re: Sunsetting Atom
#272It's what kickstarted Electron which eventually gave us VSCode, Slack, and lots of HN comments about memory usage. It also had the sweetest default theme of any code editor. RIP.
Does anyone remember brackets? I cant remember if brackets or atom came first but I remember switching from sublime to brackets to atom. Good times, I heard DHH is still using TextMate.
I still use TextMate, mainly for the excellent search & replace preview.
Re: Sunsetting Atom
#273I still prefer Atom's UX design over VSCode and I can't explain why. Amazing job on that front! I hope it gets traction with community support.
Yeah, have the same relationship, wish a UX expert could explain why my psychology is different with Atom vs VSCode
Re: Sunsetting Atom
#274I know a lot of people love vscode but are there any people who have tried something like IDEA/WebStorm/PHPStorm/etc that then went back to vscode? I had to help a developer setup deploys to a dev server from vscode the other day and I wanted to pull my hair out. I'll admit it's at least in part due to not using vscode myself but I was a heavy Sublime Text user which is very similar to vscode when it comes to how you…
I use Sublime Text, but it has its own issues with Python fragility and needing tweaks to plug-in's config files more than I'd like, so I'll probably switch to VSCode eventually.
Java IDEs seem to be living in their own world, but for everything else VSCode works well thanks to LSP. For example rust-analyzer works best with VSCode, and this makes VSCode the best Rust IDE.
Re: Sunsetting Atom
#275Earlier quoted context omitted.
It's a very dumb reason to stick with an editor, but I have trouble going back to Sublime after VSCode despite preferring most things about Sublime, because I always forget how to manage packages using Sublime's command prompt and have to screw around with it for a while each time, while VSCode has a GUI for that so the memorization required is zero, and can easily browse available packages without bouncing out to a…
Ctl-Shift-P is used in VSCode as well as Sublime. And then, "Install Package" Or through the Gui - "Preferences --> Package Control"
Sure, I find that every time I google for how to do it :-)
In VSCode, I can browse info about packages without having to remember a thing aside from "one of the six big icons on the left is 'Extensions'". One mouse click, start typing, click anything that looks like it might be good, get a ton of info and an "install" button. There are filters! So I can simply sort by "most popular" if I want, or by name, or a bunch of other things, all without having to remember anything for this somewhat-infrequent operation, because it's in the GUI.
It's mainly the integrated package exploration that's missing. And the auto-suggestion for plugins—in fact, I rarely have to do any of the above, and just click "OK" to whatever VSCode suggests, and everything's fine.
Sublime has (I just checked) a "package discovery" command, which... opens a web browser, to the exact same page you'd have ended on if you'd started by just googling it (which is what I do). So you have to find what you want on there, then go back to Sublime and find it again.
The result is that in the best case it takes me 1% as long to install what I need on VSCode (just click OK), and worst case it takes me perhaps 50% as long, compared with Sublime. I'm also way less likely to go poke around and see if there's anything that might be useful, in Sublime.
[EDIT] "Why aren't you way more familiar with the command palette?" ephemeral shells as anything more than dead-simple launchers make me really uncomfortable. I hate using them. Apple spotlight? I use it extensively—only for launching programs, period, nothing else. I'd much rather have a persistent shell environment I could attach from any terminal and leave open.
Re: Sunsetting Atom
#276Earlier quoted context omitted.
> One could imagine a world where strong standards have been established w And yet this didn't happen and Electron did. The "free market" of FOSS development settled on Electron as the winner for cross-platform development.
Yeah but that's not the whole picture - it's not just FOSS choosing Electron so much as platform holders being hostile to cross-platform development. For instance, if Apple had actually kept pace with OpenGL standards, and had embraced Vulkan, it would have been fairly straightforward to to build a native GUI framework which works across platforms. Electron won because all the platform owners basically had to embrace…
The absence of Vulkan on Apple platforms—something that it’s worth noting was developed after Apple’s Metal equivalent—is in absolutely no way even approaching a barrier to building a “native GUI framework”.
There literally are cross-platform native GUI frameworks. Even Electron itself is a third-party implementation of a GUI framework - it doesn’t use the platform’s web tech implementation and bundles its own.
Re: Sunsetting Atom
#277Founder 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?
Re: Sunsetting Atom
#278Every now and then I’m reminded of why I decided to stop chasing the shiny new and just go back to emacs.
Yeah. Which Linus uses, so probably works well enough for all non UI work whatsoever. Except maybe SQL?
Re: Sunsetting Atom
#279Founder 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…
Amazing! Sounds like a great foundation! Curious about UI execution in Rust
Re: Sunsetting Atom
#280Founder 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…
Please make zed capable of running in a terminal. If I could have a modern editor that can run in the terminal and had a nice GUI, I would definitely pick it up. There's still many instances where I'm working on a remote dev machine, on my iPad, over a serial connection, inside of tmux, where a terminal based text editor is a necessity.