Live data from Hacker News

Sunsetting Atom

github.blog

471–480 of 880 posts

Re: Sunsetting Atom

#471

Earlier quoted context omitted.

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…

That's super fair. I'll admit I'm entirely in the same boat - if nothing happens on a new tool when I type Ctrl-Shift-P, I usually just shrug and go back to using all the other tools I have that do that.

I do love the fact that, with Sublime, that 75%+ of the time when I want to do something, say, pretty-print a JSON text document, it's just:

  Ctl-Shift-P, "json"  (Don't see anything obvious)
  [hit backspace to clear json] "Install Package", "json"
  See the "Pretty Print" option, install it in 2 seconds, and on my way.

Re: Sunsetting Atom

#472

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…

Sounds interesting. I've love to take part in the alpha and provide feedback. I've done software engineering professionally for 25 years in Javascript, C++, Rust, Java, Erlang, Elixir, Clojure and Python (mostly Java and C++). I've used Emacs, VS Code, Visual Studio, and other IDEs.

https://zed.dev/waitlist

Re: Sunsetting Atom

#473

“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.

Microsoft has never understood open source. This is why they bought GitHub and npm, and paid Docker to make it work on Windows, and why GitHub and the most important parts of VS Code are proprietary software.

They use open source as a marketing buzzword, not as a philosophy, and it shows.

I think perhaps TypeScript is the only counterexample.

Re: Sunsetting Atom

#474
post #309

Earlier quoted context omitted.

Should development ever wind down, you already have the advantage of being able to announce it as "Zed's dead, baby" instead of clunky corporate euphemisms.

yet another buzzword we hear a lot these days: Zed is “lightning fast”… I hear that a lot about Rust projects, like Kitty or Alacritty

kitty is python+c++ fyi! (and as blazing as the other lightning rust software)

Re: Sunsetting Atom

#475
post #122

Earlier quoted context omitted.

I didn’t use Atom much, but I think it’s obvious that the primary reason it died was because Microsoft decided to make their own competing editor, and then bought the parent company of Atom. It wasn’t exactly the most popular editor at the time, but it did still have some users. Reminds me of how Adobe killed off FreeHand (the only competitor to Illustrator at the time) by buying the parent company and then halting d…

> the primary reason it died was because Microsoft decided to make their own competing editor > Microsoft likely gave zero shits about Atom as a competitive threat since it was effectively dead at the time anyways How can Microsoft both give zero shits because it was effectively dead, while also still being the primary reason it died? That seems to be a chicken-egg problem.

Chronology. VSCode ate Atom's lunch before MS purchased GH.

Re: Sunsetting Atom

#476
post #78

“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.

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…

I’ve never seen anyone actually using atom, so would hardly say it defined anything much less than the whole industry.

Re: Sunsetting Atom

#477
post #228

Earlier quoted context omitted.

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.

It's just one example of an impediment. If all the major platforms used a consistent standards-based graphics API, you could have one implementation of the drawing layer shared between all platforms.

All these little wedges add up.

Re: Sunsetting Atom

#478

Earlier 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 is interesting. I wonder how Emacs solves that, given that it's one of, if not THE most, extensible editor out there. I'd think that is a good thing, but never considered the drawbacks, besides performance and plugin interop that is.

Re: Sunsetting Atom

#479
post #435
post #165

Earlier quoted context omitted.

Electron is both an amazing enabling technology, and also an artifact of the sad state of affairs for computing platforms. One could imagine a world where strong standards have been established which would allow you to easily deploy lean native applications across a wide variety of platforms. Instead we ended up in this bizzare world where if you want to maintain a desktop GUI app, you either need a large team to sup…

Agreed. I know Electron isn't ideal, but as a Linux user, I have a pretty hard time complaining. In the pre-electron world, something like Slack for linux either wouldn't exist, or would be several versions behind other platforms and have some goofy UI that didn't match the rest of your desktop. At least we have it and it works.

Are you kidding? It’s a chat client that works in a browser. About as Linux friendly as it gets.

Re: Sunsetting Atom

#480
post #410
post #390

Earlier quoted context omitted.

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…

Funny how people are so different. I have never once thought that I needed my text editor to look good. Stare at anything long enough and your brain isn't even going to process it anymore! fwiw I use Linux and suspect that's a big part of why Macs never appealed to me.

A month ago I switched back to Vim, from TextMate, but still on a Mac, and honestly: Vim is kinda pretty. I spend most of my day in fullscreen Vim, and with a good theme, Airline and a pleasing font it’s just as pretty as VSCode if not more.
Post reply on HN