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

621–630 of 880 posts

Re: Sunsetting Atom

#621

Post by _puk »

nh2 wrote: post #489
frostwarrior wrote: post #412

Earlier quoted context omitted.

> 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

> Sadly, Sublime is sort of dead. Sublime has ongoing development on https://www.sublimetext.com/dev and the last major release (4) was just about a year ago.

I was under the impression that the "forced" upgrade to Sublime 4 caught quite a few out, and may have been a nail in the coffin.

I'm still rocking SLT 3, and it's my go-to for large file handling or just as a simple scratchpad, but development (of SLT) feels like it moves at a snails pace.

Re: Sunsetting Atom

#622

Post by cookiengineer »

civilized wrote: post #14
Doctor_Fegg wrote: post #7

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

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

Note that this will lead to unmaintained Electron Apps until at least 2032.

We're basically fucked.

Re: Sunsetting Atom

#623

Post by nsonha »

BaseballPhysics wrote: post #295
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…

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

I feel like people are talking about different things when they say "native", to me it's more about being compiled to native binary, or being performant, than "native UI".

I've never been impressed with native UIs in any platform, web or mobile. The only context where I appreciate them is accessibility.

Re: Sunsetting Atom

#624

Post by meanmrmustard92 »

RIP. Hydrogen [https://atom.io/packages/hydrogen] running on Atom is the cleanest multi-lingual data science IDE in existence and has been my go-to for years. Haven't found a drop-in replacement elsewhere [vscode's language support is scattered: native python integration, different for R, Julia etc].

Anyone on HN have recs [besides vim slime or send-to-terminal options in other editors, which work but are clunky] ?

Re: Sunsetting Atom

#625

Post by fendy3002 »

joshstrange wrote: post #163
csours wrote: post #103

Earlier quoted context omitted.

I use IDEA and VS Code and Notepad++ and ... I'm kind of surprised you did a deploy from VS Code. I would have assumed there was another tool for that. I do most of my git and ssh/scp stuff from the command line because I'm never quite sure what the tool will try to do to "help me out"

For myself it's all about reducing the delay between "writing code" and "seeing the results". Dropping down to scp or run a script to deploy files seems like an unnecessary delay/break in my development process that I don't like adding in. If you can develop 100% locally this isn't an issue but we can't (or haven't taken the time to do so). Think of the dev server as just a VM running locally and it might make more s…

Remote ssh to dev server and develop directly there using vscode man.

Re: Sunsetting Atom

#626

Post by oaiey »

onionisafruit wrote: post #289
alxlaz wrote: post #131

Earlier quoted context omitted.

VS Code "Pro" is very 1998. My money is on VS Code 365.

It’s already here. They went with the name GitHub Codespaces.

That is a very good analogy. Considering that Office was also an offline product before it became a cloud-subscribed web/desktop hybrid.

Re: Sunsetting Atom

#627

Post by john-titor »

Can someone explain the hype around VSCode to me? I looked into it about a year ago and was immediately turned-off by the overwhelming amount of features that they throw at you right in the 'beginner's tour'.

What I appreciate about Atom is that it is very simple right out of the box and does not get in your way. You cold always beef it up with packages later, but that progression is much more pleasant to me than the VSCode approach.

The biggest selling point of Atom to me as a Python dev was the Hydrogen package. That tight integration of notebook features within the editor is something I have never seen before and a total game changer. Especially if you are working with data that you might need to visualize a lot. Correct me if I'm wrong, but from what I understand there is no Hydrogen equivalent in VSCode? Sure, there are plug-ins that let you run your code through a jupyter kernel and display the output in a second terminal pane, but that is not the same as the ability to simply highlight a bit of code, run that and have the results displayed immediately on the next line below. Having pyplot figures displayed in such a way is also not possible from what I saw, or did I miss something?

Re: Sunsetting Atom

#628

Post by [deleted] »

blagie wrote: post #601
theteapot wrote: post #555

Earlier quoted context omitted.

> I code mostly in domain-specific, esoteric, private languages, no stdlib or docs, and no online resources to learn from. Jesus, who are you?

There are also a whole bunch of languages for: - Describing levels in video games, which are primarily data with code mixed in - Describing transformations of different sorts (e.g. the types of languages used in compilers for specifying a programming language parser, and then optimizations) - Defining hardware (analogues to Spice, Verilog, and VHDL). Hardware can also include mechanical objects, as well more broadly,…

[deleted]

Re: Sunsetting Atom

#629

Post by jeppester »

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…

In VS Code the collaborative editing (live share) seems like a dirty workaround put on top of an architecture not built with multiple users in mind.

I use live share all the time because it's the best thing we have for pair programming, but I often wish for a better solution. We often get disconnected for no reason, editors get out of sync, terminal sharing is near useless.

If you can produce something that doesn't feel like a hack, then I'm all in!

Features I would love to have:

- Terminal sharing should work like tmux with window size "smallest". It's the best solution I've found for having a shared terminal.

- Let us join a collaboration session from the terminal: `zed [URL]`. No annoying website that takes ages to open, or having to open the editor before joining the session.

- Let me start a server on a port and let others join that server. I can forward that port if I need to.

- Let me start a headless server on a shared dev env, and let me and others connect to collaborate

Re: Sunsetting Atom

#630

Post by oaiey »

sneak wrote: post #473
Doctor_Fegg wrote: post #7

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

I think they understand open source (and show it by many projects) but like you said, it is not their core philosophy.

They are a proprietary software and cloud vendor super house. They are very successful like that. Open Source is 3-4 level down to their main strategy.

Post reply on HN