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

411–420 of 880 posts

Re: Sunsetting Atom

#411

Post by boringuser1 »

wpietri wrote: post #337
nathansobo wrote: post #300

Earlier quoted context omitted.

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…

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?

No post body was provided.

Re: Sunsetting Atom

#412

Post by frostwarrior »

shakow wrote: post #352
quaunaut wrote: post #286

Earlier quoted context omitted.

Atom practically invented the kind of extensions that VSCode had, and even several years into VSCode's life Atom far outstripped it in Extensions. Perf became the biggest problem however, which VSCode took over.

> Atom practically invented the kind of extensions that VSCode had Let me introduce you to Emacs, vim, Sublime, TextMate, ...

> Emacs, vim

Unlike VSCode, Emacs and Vim have a learning curve. And turning them into full blown IDEs makes their usage even more complex.

> Sublime

Sadly, Sublime is sort of dead.

> TextMate

TextMate: Text editor for macOS

Re: Sunsetting Atom

#413

Post by Shish2k »

nathansobo wrote: post #334
ilovecaching wrote: post #280

Earlier quoted context omitted.

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.

We have graphics, but I could see a mode where you `scp` a headless moon lander version of Zed up to a remote server to do remote development. VS Code has a feature like this but I hadn't used it much before switching to Zed full-time.

> VS Code has a feature like this but I hadn't used it much before switching to Zed full-time.

Please check it out — being able to edit / run / debug code on a linux server using a mac desktop over ssh, and having the whole experience be as seamless as edit / run / debug locally, is a huge win — it's pretty much _the_ reason that I’m currently using VSCode 90% of the time despite being a huge JetBrains fan (to the point of paying for their full enterprise pack out of my own pocket)

(JetBrains tools do kind-of support remote file editing, but it’s flaky and slow, and remote run / debug are a nightmare — compare to VSCode, where I sometimes mix up local and remote development because they’re identical except for the hostname in the titlebar when running remotely)

Re: Sunsetting Atom

#414

Post by 5e92cb50239222b »

DonHopkins wrote: post #368
frostwarrior wrote: post #194

Earlier quoted context omitted.

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.

What? MySQL continues to work just fine. 8.0 (which was admittedly released two years ago) was the biggest release in ages in terms of new features and removal of things that should have been removed decades ago. Then there's MariaDB, which is named differently purely for copyright reasons and could be considered the 'real' MySQL (since its dev team are Monty and friends). I don't think MySQL came out of Sun's disintegration badly at all.

To be more precise: 8.0 finally has proper utf-8 out of the box, support for complex replication topologies (including multi-master), window functions, CTEs, etc.

Re: Sunsetting Atom

#415

Post by nathansobo »

behnamoh wrote: post #397
pvg wrote: 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

"Real real fast"

Re: Sunsetting Atom

#416

Post by shakow »

frostwarrior wrote: post #412
shakow wrote: post #352

Earlier quoted context omitted.

> Atom practically invented the kind of extensions that VSCode had Let me introduce you to Emacs, vim, Sublime, TextMate, ...

> Emacs, vim Unlike VSCode, Emacs and Vim have a learning curve. And turning them into full blown IDEs makes their usage even more complex. > Sublime Sadly, Sublime is sort of dead. > TextMate TextMate: Text editor for macOS

> Unlike VSCode, Emacs and Vim have a learning curve.

That's not the point, we were talking about plugins.

Re: Sunsetting Atom

#417

Post by sk0g »

tinco wrote: post #225
blackoil wrote: post #129

Earlier quoted context omitted.

> VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase It isn't true anymore then saying Slack is rewrite of Atom. While it is using electron, editor and IDE aren't from Atom.

Slack does not aim to build a superset of features of Atom.

IntelliJ idea also includes most or all features Atom does, but that does not validate this statement:

> VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase

They both use Electron as their framework, but that's about where the code similarities end.

Re: Sunsetting Atom

#418

Post by nathansobo »

greyhair wrote: post #392
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…

Just make it keyboard centic. I don't want to touch the mouse.

Definitely a priority.

Re: Sunsetting Atom

#419

Post by enahs-sf »

frostwarrior wrote: post #412
shakow wrote: post #352

Earlier quoted context omitted.

> Atom practically invented the kind of extensions that VSCode had Let me introduce you to Emacs, vim, Sublime, TextMate, ...

> Emacs, vim Unlike VSCode, Emacs and Vim have a learning curve. And turning them into full blown IDEs makes their usage even more complex. > Sublime Sadly, Sublime is sort of dead. > TextMate TextMate: Text editor for macOS

At risk of dating myself, I am still rocking with sublime text and vim.

Re: Sunsetting Atom

#420

Post by joshstrange »

bastardoperator wrote: post #384
roflyear wrote: post #325

Earlier quoted context omitted.

Yeah almost an anti pattern.

No almost about it, it's an anti-pattern and I personally would consider it a "worst practice". If you're deploying from an IDE it means you lack visibility, feedback, and automation fundamentals. What I do like is developer ownership and being able to see a change all the way through to production but having a system of record without manual intervention is always preferred.

It's always so interesting to see people who have no concept of your stack/problem-space speak so confidently about what you must be doing wrong.

I don't know if you've just chosen to assume the worst or don't care enough to think about it for more than a second but I've been very clear in all my comments that these are developer-specific machines we are deploying to. It's literally no different from running VMs on your local machine. There is full visibility and feedback, we aren't deploying to Prod or even QA, this is development where each developer has 2 or more boxes owned by them and only them. We also are working with specific custom hardware that our code runs on which is one reason we can't easily do this locally.

To jump in and call that "worst practice" is just lazy and condescending. On top of that, it's completely wrong.

Post reply on HN