Github announced new IDE GitHub Codespaces · GitHub and it’s name suggests Github now working with VSCode.
Since developing 2 free code editor in 1 company is bad idea, And before codespace, co development of VSCode and Atom is possible because Microsoft and Github is technically not same company.
My assumption is that announcement of codespace means that from now on, GIthub will put their dev on development of Codespacce and stop supporting Atom. And commit graph seems gave a weight to my assumption…
From the above link one can get the impression that codespaces are a complete different thing: " How is Codespaces different from VS Code?
Codespaces sets up a cloud-hosted, containerized, and customizable VS Code environment. After set up, you can connect to a codespace through the browser or through VS Code."
So you will get a development environment inside a cloud based container, whereas atom, at least the way I am (not) using it, is a local editor, editing mostly local source files.
GitHub Codespaces is essentially a rebranded and more github integrated version of Visual Studio Codespaces.
You can get a pretty good sense how this will all work by reading this post of mine, and the VS Codespaces documentation.
Broadly speaking there are two ways to work with this: you can run a version of VS Code entirely in the browser that is connected to a cloud hosted computing environment, or you can connect your local VS Code to that same cloud hosted computing environment.
I don’t see any indication that Atom devs have been moved to codespaces, as far as I can tell codespaces is a product that really originated from the Visual Studio team.
But looking at the commit activity on Atom’s repository, it seems that they must have gone somewhere? I was quite shocked to see the low activity level.
The only part of Atom that’s seen any significant work on features in the last couple of years is the git/github extension. AFAICT most (if not all) of Atom’s core devs have moved on to other projects. As the commit graph shows, this isn’t really a new development.
Now, as for what this means for Juno: We’ll definitely keep supporting the current Atom-based plugins for the foreseeable future, but a switch to VSCode is becoming more and more likely.
Per a Reddit AMA from 2018, Microsoft will develop and support both Atom and VS Code. Of course that’s 2 years ago so whether it still holds true is anyone’s guess.
Atom, I believe, is a mature product and development tends to slow down. Especially since they have the whole plugin module, that means if you want to add a feature to Atom you do it with a package, NOT modifying the core of the atom code. Atom is basically a platform for plugins the way Julia is platform for the package manage.
I would assume issues against atom are still being closed. It would be interesting if they had a graph of the “issue close rate” vs “new issue rate”.
Besides could you see them doing a major overhaul of Atom? If they tried to make the interface “better” half the users would scream bloody murder. And half the packages would probably break, so people who like the improved look would be pissed their packages no longer worked. Or if they tried to improve the package integration, and broke existing APIs so that all the package owners needed up update their code…more pitchforks.
A software project of this type has to keep moving or it’s dead. The idea that Atom is so far ahead of VS Code that they can stop working on it is hard to take seriously.
The picture you are painting here is of a software zombie, not a vibrant living project. I sincerely hope that the state of Atom is not as dire as the image you are presenting.
The writing has been on the wall for Atom (for two years, as you already know), but I completely understanding maintaining Juno on atom temporarily due to the differences in IDE features for interactivity. But it is time… The sooner you rip off that bandaid the better, as far as I am concerned.
My biggest concern is what happens when you do decide to move to vscode . Is this going to be a competing and incompatible extension relative to the existing one? Are you joining forces? Would this be an additional, optional, layer on top of the base vscode installation, etc.
Normally I am all for competition driving innovation, but network effects of having users on the same platforms and not spreading precious develop time thin far outweighs any of those gains (for now at least).
Well, Atom isn’t magically becoming worse by the day just because there’s almost no feature development going on. VSCode has only fairly recently (within the last year or so) offered significant advantages as a platform when compared to Atom plus the Juno infrastructure that we had already built.
Not sure. Julia-VSCode and Juno have fairly different design philosophies, and I’m too unfamiliar with the julia-vscode codebase to know how feasible it is to extend it or whatever. We’d definitely want to work with (and help improve) the Julia language server though.
This is a good example of why it has been wise to invest more in development of modular components of an IDE than a single unified codebase. Editors will come and go but we can continue to develop the components with a fair degree of confidence they will be useful for years to come.
That is certainly the approach we’ve taken in VS Code. Pretty much all of the code editing functionality lives in LanguageServer.jl, which is independent of VS Code and actually can be used from VIM, Emacs and lots of other editors as well.
The new plot viewer that we will hopefully merge soon is also quite independent of VS Code, it also powers ElectronDisplay.jl.
In general I’d say that the various parts of the VS Code Julia extension are quite distinct and independent from each other.
I would have thought that the biggest difference is how the code editing support is implemented, i.e. the language server approach in VS Code that is pretty static and in principle does not rely at all on the state of the REPL? I think in Juno it does, or not?
Maybe a good first step to scope this out would be to come up with a list of things that Juno can do right now that we don’t have in the VS Code extension, and then figure out how and whether that could be added to the VS Code Julia extension? And where there are actually differences in philosophy that matter? I’d be happy to go through that exercise jointly.
Have you thought about using/joining forces with JuliaFormatter.jl instead of continuing to maintain DocumentFormat.jl separately? It also uses CSTParser under the covers, so there shouldn’t be a huge impedance mismatch there.
Would not have asked this question if I had spent 2 seconds searching on github to find there’s already been a discussion of the topic:
