As GitHub Retires 'Atom', Open Source 'Pulsar' Continues Its Legacy

In June GitHub announced they'd retire their customizable text editor Atom on December 15th — so they could focus their development efforts on the IDEs Microsoft Visual Studio Code and GitHub Codespaces. "As new cloud-based tools have emerged and evolved over the years, Atom community involvement has declined significantly," according to a post on GitHub's blog.

So while "GitHub and our community have benefited tremendously from those who have filed issues, created extensions, fixed bugs, and built new features on Atom," this now means that:

- Atom package management will stop working
- No more security updates
- Teletype will no longer work
- Deprecated redirects that supported downloading Electron symbols and headers will no longer work
- Pre-built Atom binaries can continue to be downloaded from the atom repository releases

Fortunately, in 2014 GitHub open sourced the code for Atom. And according to It's FOSS News: A community build for it is already available; however, there seems to be a new version (Pulsar) that aims to bring feature parity with the original Atom and introduce modern features and updated architecture....

The reason why they made a separate fork is because of different goals for the projects. Pulsar wants to modernize everything to present a successor to Atom. Of course, the user interface is much of the same. Considering Pulsar hasn't had a stable release yet, the branding could sometimes seem all over the place. However, the essentials seem to be there with the documentation, packages, and features like the ability to install packages from Git repositories....

As of now, it is too soon to say if Pulsar will become something better than what the Atom community version offers. However, it is something that we can keep an eye on.... You can head to its official download page to get the package required for your system and test it out.
Like Atom, Pulsar is cross-platform support (supporting Linux, macOS, and Windows).

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:

[AmiMoJo]

VS Code is a current product and under active development.

It's a decent IDE once you figure it out. Opens fast, supports almost everything, git support built in... Good stuff.

I wish more things would adopt it. In the embedded world everyone seems to use Eclipse as the basis for their editor, and it's terrible.

Re:

[account_deleted]

Comment removed based on user account deletion

Re:

[AmiMoJo]

Discoverability is an issue with the command line, I agree. The sad fact is that most IDEs are so bad that it's a relatively minor blemish.

Re:

[L.Kynes]

VS Code is a current product and under active development. It's a decent IDE once you figure it out. Opens fast, supports almost everything, git support built in... Good stuff.

I like that I can use VS Code on my Mac, Linux and Windows machines. Doing some cross platform development. I use vsc only as a text editor and use msys2, gcc and clang from standard terminal.

pluses: can handle files with gigabytes of data, fast (indexed) grep like search in thousands of text files in total 100 GB, automatic code index to jump to definitions etc., remote connections to work on another machine

minuses: different keyboard shortcuts than MS Visual Studio, takes lots of RAM - about 1 GB pe

Re:

[arglebargle_xiv]

I use VC++ 6 as my editor and code checker for embedded work (yeah, embedded is pretty much just raw C, so a 1998 IDE is fine). Then once the code is written and syntax-checked I build and run in whatever thing is needed for the target.

This thing checks and builds code, oh, about a hundred times faster than anything available today, and alongside that it sucks vastly less than Eclipse and isn't a bug-riddled PoS like Visual Studio's editor, which I assume is the same thing as VS Code.

Re:

[AmiMoJo]

My favourite one is Atmel Studio, which is based on Visual Studio 2017.

I know someone else who used to use MSVC to check C code before moving to embedded. I mostly just rely on GCC for that, although since ARM decided to make Clang the official compiler I end up using that a lot now.

Re:

[arglebargle_xiv]

I've been trying to find some balance in VS where it's still fast (both editing and compiling) but before the massive crapification and bloat of recent versions set in because VC++ 6 is missing a few things that some embedded code needs, variadic macros spring immediately to mind. Anything after about 2015 is just too painful to endure, and the rot started setting in around 2012 or a bit earlier, but then according to various web posts 2005 at least probably won't run under Windows 10. Perhaps 2008?

Re:

[arglebargle_xiv]

Replying to my own post, just remembered they did their big UI fuckup starting with VS 2010, so it's VS 2008 or nothing.

Advice

[backslashdot]

If you are too much of a pansy to use vi, then at least use sublime. Oh yeah and do not use version control. You do not need it. Just save copies of the file with a date, or better yet, random keyboard characters appended on the end of it. Keep in mind real men do not need the previous version of their code.

Re:

[Entrope]

Ed is the standard text editor [gnu.org]. Note the consistent user interface and error reportage.

Re:

[pz]

Patl, is that you?

Re:

[CaptainLugnuts]

You pansies with ed. I learned how to program C with e, ed's predecessor.

You could type in lines, delete lines, or run regex search and replace on lines. It really sucks having to type in your typo in order to fix it.

Luxury!

[presidenteloco]

Back in my day, we had to write our own line by line text editor in Pascal, then print out the edited code on sheets and sheets of paper with holes in it then read carefully line by line (search wasn't even a twinkle in someone's eye) to hunt for bugs.

Re:

[jmccue]

I have not seen a vi vs emacs war in a long time.

So, emacs for the win as a IDE :)

If you're not using Emacs

[nagora]

Then you're doing it wrong.

Everyone Should Fork--From Github

[BrendaEM]

There's a reason why M$ wanted it.

Re:

[RazorSharp]

There's a reason why M$ wanted it.

Exactly. When Microsoft buys a business, the intention is to tie the general public into the Microsoft ecosystem. Their entire corporate philosophy rejects the idea that a profitable niche is a success. They believe all software must run through them—whether it's their OS, cloud, languages, development tools, app store, or repository. Can't crush Linux? Fine, own Linux instead.

I understand that moving off Github is a pain in the ass for projects that have been around for a while, but Microsoft is a di

vim will never die

[Jeremi]

vim's user interface may suck, but the important thing is that it sucks consistently across every OS and will continue to suck in the exact same ways, forever.

vim won't get "retired" by Google or by anyone else. vim will run on any operating system you want to develop on. vim will run on an 8086 with 640kb of RAM. vim will run over a 300 baud serial connection, if that's what it takes to get the job done.

Once you've suffered through the requisite 8 weeks of learning vim's quirks, you'll never have to lea

I tried 1.100.2022121819 portable

[gTsiros]

It took 34 seconds to show the window. I run it again. It took 34 s again. I have the executable excluded from windows's antivirus scanning.
Visual studio 2022 (preview) _with_ the previous solution loaded on startup takes 5 s. More like 4 s, but I'll be generous and say 5 s.
I have a 5950x, 64 GB @ 3600 and a 500 GB "960 evo" samsung ssd.

I do not know what to make of this.

Ooooh... the executable contains node.js, chrome and about a GB of stuff in a "resources" folder.

This is not a text editor. This is an operating system with... support for at least two programming languages (js, glsl).

I miss the days when an entire IDE was significantly less than 10 MB.