I hope the main thing you leaned is that people want a text editor to start up in less than a second
Sunsetting Atom
521–530 of 880 posts
Re: Sunsetting Atom
#522I will admit that I'm biased, I hate to use Microsoft products. I hate Bill Gates and I hate Microsoft. I will not be switching to VsCode just on principal. Yes, I'm still using Github, so I guess I'm a walking contradiction. I also understand the economics of this situation why keep Vscode and atom IDE can't co exist, i'm surprised it took so long. This is the second software application that Microsoft has ruined, r…
3rd actually, Sunrise was a fantastic calendar app. Microsoft is a blight on the world.
Thanks!
Sometimes it feels like I live all alone with my hate for Microsoft/Gates, but I'm glad I'm not alone.
Re: Sunsetting Atom
#523Earlier quoted context omitted.
We plan to monetize collaboration. Zed is a collaborative platform disguised as a world-class code editor.
How often do developers want to edit the same file, at the same time, and have those updates occur in real-time? I see this as a compelling feature for something targeting the use cases of, say Google Docs, where multiple people are contributing to an outline document or a business plan at the same time - but for code, I don't quite see the appeal.
> How often do developers want to edit the same file, at the same time, and have those updates occur in real-time?
That's a very specific example of collaboration. Remote work is exploding. What about, say, integrated, collaborative debugging or code review? Integrations with things like Slack?
Re: Sunsetting Atom
#524Earlier 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?
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…
Hey there. I've been thinking about implementing an editor agnostic WASM based plugin framework and started prototyping with some promising results, although there are also a lot of of WASM related constraints to consider.
I think cross-platform plugins would be hugely beneficial for the whole ecosystem, and also generally for new editors since they can potentially benefit from a larger plugin developer community.
Is that something you can see your team collaborating on?
Re: Sunsetting Atom
#525Earlier 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?
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…
If you make Python a first class citizen and give it special support, you won't be disappointed.
Man that felt a bit like extortion, but I mean well.
Re: Sunsetting Atom
#526Vscodium + LiteXL[0] replaced Atom + Sublime for me.
Re: Sunsetting Atom
#527“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…
> 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.
One should make a difference between (1) access to the source code to look, find bugs, make minor adjustments and (2) everybody with that access to be able to actively participate in the development.
In the sense of (1), open source is "some part of a commons". That's what the license gives you.
In the sense of (2), open source may or not be open to a community approach. It's fully legitimate for some company or other group of maintainers to provide (1) but deny anything related to (2). You are free to fork and make your own community, but there is nothing that guarantees you that your pull requests are accepted or even looked at, bug reports reacted to or anybody listening to wishes, concerns or other opinions about the project. It's nice if that's provided, and one could argue that some part of the spirit of open source is to enable a community, which in turn helps the original creators (and could be a major motivation to open source something), but nobody should be upset if maintainers choose otherwise.
It's nice if it's clearly communicated how maintainers see this though.
Re: Sunsetting Atom
#528Earlier quoted context omitted.
> custom native UI framework Cool project, but this is clearly a contradiction. wxWidgets? That offers a native UI. Wherever possible it uses the UI controls from the underlying OS/system to render the interface. Looking at the project page it describes "a GPU-powered UI framework that met our needs." That's not a native UI. That's a non-native UI compiled to native code, ala something like Flutter.
"Native UI" can be interpreted to mean "UI written in native (i.e compiled to machine) code" or "UI written using the OS's native widgets". You are presuming that the only correct definition is the latter, but it's pretty clear from context that they mean the former.
> but it's pretty clear from context that they mean the former
It absolutely was not clear, which is why I checked the website and then pointed out the lack of clarity.
At first my thought was "Wow, nice, another UI toolkit that uses native widgets, that's good!" But, alas, it was not to be.
Re: Sunsetting Atom
#529“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.
just fork it, no one is stopping ;)
Re: Sunsetting Atom
#530I think the most essential feature that vscode had over atom was good default features, once I see my coworker struggle for an hour to setup a dev env and I decided it is not going to be the tool of my profession