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

361–370 of 880 posts

Re: Sunsetting Atom

#361

Post by nathansobo »

mwcampbell wrote: post #343
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…

zed sounds like a great project. What are your thoughts on the existing Rust GUI frameworks? Naturally the core editor widget will need to be custom no matter what, but for the rest of the UI, have you considered using one of the Rust GUI frameworks already being developed?

When we started on Zed the Rust UI framework space was much younger. In absence of a mature solution that met our exact needs, the simplest path for us was to build it ourselves. We're too far into things now to change at this point.

Re: Sunsetting Atom

#362

Post by shakow »

nathansobo wrote: post #329
tiffanyh wrote: post #321

Earlier quoted context omitted.

Re: Native UI Is Zed web-based or not? Would it be able to be hosted in the browser like the web-based version of Github Codespace (Visual Studio Code Online)?

We plan to compile to WebAssembly that writes pixels to a WebGL canvas.

If you will directly write yourself everything to a GL canvas anyway, what do you gain by going through a whole WebGL dependency & context rather than just using a native OpenGL context?

Re: Sunsetting Atom

#364

Post by danuker »

presentation wrote: post #261
joshstrange wrote: post #174

Earlier quoted context omitted.

> You're deploying via VS Code? If so, that's a weird pattern. I don't think it's a weird pattern, maybe a slightly legacy one but not out of the ordinary. I've seen this pattern used at multiple places (not implement by me). It makes sense if you have special use-cases where you need to use physical hardware and/or a local stack is too heavy or complicated to run.

Though why does it need to be in your editor vs some command line tools or something else?

So you can deploy at a moment's notice. Why run a command instead of hitting a key combo? Or even deploy as soon as tests pass?

Software should allow that. Especially software for writing other software.

Re: Sunsetting Atom

#365

Post by mwcampbell »

nathansobo wrote: post #361
mwcampbell wrote: post #343

Earlier quoted context omitted.

zed sounds like a great project. What are your thoughts on the existing Rust GUI frameworks? Naturally the core editor widget will need to be custom no matter what, but for the rest of the UI, have you considered using one of the Rust GUI frameworks already being developed?

When we started on Zed the Rust UI framework space was much younger. In absence of a mature solution that met our exact needs, the simplest path for us was to build it ourselves. We're too far into things now to change at this point.

Fair enough. Hopefully when you're ready to work on accessibility in your UI framework, AccessKit [1] will be ready. I'm hoping to have usable Windows and Mac implementations by the end of this year.

[1]: https://github.com/AccessKit/accesskit

Re: Sunsetting Atom

#366

Post by input_sh »

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 just wanted to say I really liked your product and despite multiple attempts to switch to VS Code (in anticipation of this day), I kept returning to Atom. I don't know why, I could never get VS Code to feel right to me, while Atom always felt right despite many of its quirks I've gotten used to over the years.

Looking forward to its spiritual successor!

Re: Sunsetting Atom

#367

Post by nathansobo »

gigatexal wrote: post #349
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…

Add a really good vim mode and I’m there.

Earlier this year Keith Simmons, the author of Neovide (https://github.com/neovide/neovide), joined our team. He's been working on Vim bindings and paying a lot of attention to getting it right. As you probably know there's a lot of surface area, so this will take time.

Re: Sunsetting Atom

#368

Post by DonHopkins »

frostwarrior wrote: post #194
mumblemumble wrote: post #47

Earlier quoted context omitted.

The code isn't being sunsetted, and anyone who wants to take it and keep working on it is free to do so. But winding down the project is still a major event, and I think that it is appropriate to call that sunsetting. The existing project organization will go away. The team will presumably dissolve, with any people being paid to work on it going on to other things. I've seen this happen enough times to know that it i…

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.

There are some things worse than death, like what MySQL experienced: being turned into a zombie designed to eat the brains and infect people who used to use it when it was truly free, all in the name of tricking people into switching to Oracle's expensive SQL server.

Re: Sunsetting Atom

#369

Post by amanwithnoplan »

kylebarron wrote: post #244

I personally found Atom + Hydrogen [0] to be the most productive interactive Python environment I've ever used. I really want to see VSCode adopt some way to run a Jupyter kernel for a Python file (with a notebook UI) and have rich results in line with the code (i.e. not a terminal output off to the right side of the screen). [0] https://github.com/nteract/hydrogen

VSCode already does that as of some versions ago.

https://code.visualstudio.com/blogs/2021/11/08/custom-notebo...

https://code.visualstudio.com/docs/datascience/jupyter-noteb...

Re: Sunsetting Atom

#370

Post by llllllllllll9 »

tediousdemise wrote: post #37
civilized wrote: post #14

Earlier quoted context omitted.

GitHub is owned by Microsoft, the company that invented "Embrace, Extend, Extinguish". We should be counting down the days till they sunset VS Code to focus on VS Code "Pro".

When this inevitably happens to VSCode, I'm sure we'll all flock to Sublime Text in droves (or some hip new editor on the block). Contingency planning for this could be a small but wise time investment for dependent teams. VSCode could very well go the way of the Do... Docker.

:)
Post reply on HN