# Github annouced codespace. does it mean Atom is now abandoned?

**URL:** <https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923>\
**Category:** Community\
**Created:** [May 7, 2020, 1:03am UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923 "2020-05-07T01:03:59Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![tbeason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tbeason/32/15898_2.png) [@tbeason](https://discourse.julialang.org/u/tbeason)\
**Post date:** [May 7, 2020, 6:36pm UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/21 "2020-05-07T18:36:03Z")

</div>

In a sadistic way, I’m kind of glad. Being a VS Code user, I always wondered if I was missing out on cool stuff with Juno. Now – no more regrets. I like options but I almost want them to disappear after I’ve made my choice! (competition is always good of course)

---

<div class="post-metadata">

**Author:** ![jlperla](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlperla/32/34332_2.png) [@jlperla](https://discourse.julialang.org/u/jlperla)\
**Post date:** [May 7, 2020, 11:21pm UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/22 "2020-05-07T23:21:00Z")

</div>

> [@pfitzseb](#):
>
> Well, Atom isn’t magically becoming worse by the day just because there’s almost no feature development going on.

Of course not, but the entire experience does if you move to vscode for everything else. I prefer many of the features in Juno, but almost always use vscode for julia, just because I use it for latex and all my other work.

Furthermore, new users are much more likely to be either (1) using vscode; or (2) quickly figure out that Atom is a deadend… .

> [@tbeason](#):
>
> (competition is always good of course)

That is not necessarily true (in both theory and practice).

As soon as the payoffs are supermodular (or you could check complementarity with cross-derivatives), there are all sorts of places where competition can make things worse. This is especially true in models with network effects, which have high degrees of complementarity, and in two-sided markets (e.g. platform choice such as that of a editor).

---

<div class="post-metadata">

**Author:** ![tbeason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tbeason/32/15898_2.png) [@tbeason](https://discourse.julialang.org/u/tbeason)\
**Post date:** [May 8, 2020, 12:07am UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/23 "2020-05-08T00:07:53Z")

</div>

Yes yes of course. But one can throw many wrinkles into the mix (heterogeneous preferences?). In this case, for example, many people probably still have a big dislike for Microsoft, so this could be a negative in their view. I also don’t disagree though that we might be better off if we all decided on a single IDE and focused our efforts there.

---

<div class="post-metadata">

**Author:** ![v-i-s-h](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/v-i-s-h/32/46152_2.png) [@v-i-s-h](https://discourse.julialang.org/u/v-i-s-h)\
**Post date:** [May 8, 2020, 5:02am UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/24 "2020-05-08T05:02:23Z")

</div>

I use Julia with VSCode and the most recent developments in VSCode Julia-extension make it competitive to Atom. Initially, I started with Atom, but it became very slow, and then I jumped to VSCode. I was wondering when Juno will move to VSCode. As now the discussion is also about switching Juno to VSCode, there may be one more option to consider.

Eclipse Theia ([https://theia-ide.org/](https://theia-ide.org/)) is an opensource alternative to VSCode which brings foundation for both Desktop as well as cloud IDE. As far as I know, Visual Codespaces is not opensource. Theia also claims to be compatible with VSCode extensions (though not sure about the specifics). So building a Julia IDE around Theia keeps up with the opensource spirit.

Moreover, JuliaBox from Julia computing now provides only a notebook interface (?). My understanding from this is Julia Computing is ready to host a computing environment (of course, now, paid). But as Julia reaches more audience, it may be worth to host a complete cloud IDE also in JuliaBox to attract more customers. Since Theia has both Cloud as well as Desktop IDE capabilities, it makes more sense to have this unified solution. If both contributing volunteers and Julia computing can pool in, then the development can also be accelerated and we can soon have a working IDE.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [May 8, 2020, 7:18am UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/25 "2020-05-08T07:18:44Z")

</div>

> [@tbeason](#):
>
> we might be better off if we all decided on a single IDE and focused our efforts there

I would be a bit cautious about this. As the example of Atom shows, IDEs can come and go in the span of a few years, depending on corporate backing and/or developers migrating to the next great project. (The only editors that have been around for decades are Emacs and Vi.)

Instead of picking a winner, I would advocate that IDE-related tooling is moved to (or kept in) packages that are IDE-agnostic to the extent possible, so that resources can be pooled between users/developers of various editors. A “thin” (😉) layer can expose this to each IDE. This is of course already happening to a large extent — let’s just keep it this way.

---

<div class="post-metadata">

**Author:** ![pixel27](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pixel27/32/8902_2.png) [@pixel27](https://discourse.julialang.org/u/pixel27)\
**Post date:** [May 8, 2020, 11:49am UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/26 "2020-05-08T11:49:58Z")

</div>

I also wouldn’t call Atom “dead”. It’s open source. That means if people like it enough and the current masters are not giving it enough love, someone can always fork it and “take over.” Or the current master’s could give control to another group.

I suspect before that will happen though, it needs to “degrade” enough that someone get’s fed up and wants to take control.

---

<div class="post-metadata">

**Author:** ![aviatesk](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aviatesk/32/7610_2.png) [@aviatesk](https://discourse.julialang.org/u/aviatesk)\
**Post date:** [May 8, 2020, 3:58pm UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/27 "2020-05-08T15:58:52Z")

</div>

> [@davidanthoff](#):
>
> 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.

This sounds very good idea. I’ve tried to list up what components are essential for Juno and whether they can be realized in VSC or not. AFAIU the features that makes Juno unique and powerful can’t be implemented in current VSC (like interaction with running session via inline results), but the thing is that VSC may be able to provide extension APIs for those features in the future. Maybe no one knows the estimate of that, but I’m sure David has more ideas on this than me.

As for the discussion on whether we should focus our efforts on a single IDE project, I rather want to say we should keep choices for various coding styles for programmers at least. vscode-julia extension offers very nice IDE features based on static code analysis (like what other IDEs do so) while Juno enables very interactive coding style (like Jupyter does). (so imho the current situation is not so bad in that sense) If it’s possible to realize those styles of coding style all in VSC, it would make sense to focus our efforts on that.

---

<div class="post-metadata">

**Author:** ![davidanthoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/davidanthoff/32/223493_2.png) [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)\
**Post date:** [May 9, 2020, 12:46pm UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/28 "2020-05-09T12:46:34Z")

</div>

@aviatesk do you have that list somewhere? I’d be very interested to take a look. What is a good place to have these discussions for individual features?

My sense is that the one feature that really can’t be implemented with the current VS Code API is the inline viewing of eval results. MS had been working on an API for that, but it is unclear to me how much they are pushing that right now.

Having said that, we _are_ getting a full notebook UI, which should make for a very Jupyter like experience. Obviously not exactly the same thing as the current Juno story, but I think it will make a big step for using the VS Code extension for interactive and explorative work. You can try the current (very buggy and incomplete) implementation over at [Add notebook controller implementation by davidanthoff · Pull Request #980 · julia-vscode/julia-vscode · GitHub](https://github.com/julia-vscode/julia-vscode/pull/980). You’ll need to use VS Code Insiders, and then just create an empty `.jlnb` file and open that.

I think the other major feature we are missing is a workspace viewer, but I’m pretty close to finishing an implementation for that at [https://github.com/julia-vscode/julia-vscode/pull/1003](https://github.com/julia-vscode/julia-vscode/pull/1003).

Beyond that, I’m not sure what else in terms of major features is missing?

---

<div class="post-metadata">

**Author:** ![Ronis\_BR](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ronis_br/32/50999_2.png) [@Ronis\_BR](https://discourse.julialang.org/u/Ronis_BR)\
**Post date:** [May 9, 2020, 2:27pm UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/29 "2020-05-09T14:27:39Z")

</div>

That’s why I use Vim or Emacs (with Evil mode) 🙂

---

<div class="post-metadata">

**Author:** ![marius311](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/marius311/32/3953_2.png) [@marius311](https://discourse.julialang.org/u/marius311)\
**Post date:** [May 9, 2020, 10:51pm UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/30 "2020-05-09T22:51:25Z")

</div>

> [@davidanthoff](#):
>
> 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

My 2c. I’m an Atom user but probably every six months I mess around with VSCode to see how far its come (the whole thing, not just the Julia part). I did this week too and this time I was really impressed. As someone constantly working on various HPC clusters, the remote workspaces alone is soooo good now and pretty much solidifies I’m going to move to all VSCode some time in the future.

That said, for Julia I will probably stick with Juno for now. FWIW, I think the minimal things that would get me to switch are:

- Inline evaluations, both run-block (displays output on the side) and run-cell (displays output below, sort of like a notebook), with expandable “drill-down” outputs for both. Sounds like notebook-style displaying outputs below is coming to VSCode which is great, but unfortunately the run-block style is what I use more, because the outputs don’t expand anything to make space, so you don’t get visually disoriented of where the code is in your original file.

- Evaluate into current module and change module. I don’t think its been mentioned here but for me its critical for package developement to open some file which is included in some module and when I evaluate stuff in it, I’m evaluating in that module.

Beyond that, there’s still a bunch of details which are really nicely polished in Juno that would be nice to have, including

- Profiler, especially including the thing Juno does where your lines of code get highlighted with a bar that has a length proportional to runtime.
- Stack traces highlighting lines of code included in the trace as red, for extra easy tracing of errors.
- Entering debug for single statements within a running session (in VSCode I could only figure out how to debug a whole file and also it always starts a new session? maybe I’m missing something though) and “Step to Next Expression”.

Anyway, that’s my perspective on it, ultimately both tools are very good and you guys all deserve alot of credit for the hard work you’ve put in.

---

<div class="post-metadata">

**Author:** ![ssfrr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ssfrr/32/3736_2.png) [@ssfrr](https://discourse.julialang.org/u/ssfrr)\
**Post date:** [May 9, 2020, 11:08pm UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/31 "2020-05-09T23:08:12Z")

</div>

+1 to all of marius311’s post. Those are my favorite Juno features as well (particularly the profiling and debugging integration into the editor pane)

---

<div class="post-metadata">

**Author:** ![tk3369](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tk3369/32/2824_2.png) [@tk3369](https://discourse.julialang.org/u/tk3369)\
**Post date:** [May 10, 2020, 9:52pm UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/32 "2020-05-10T21:52:19Z")

</div>

> [@davidanthoff](#):
>
> What is a good place to have these discussions for individual features?

How about a virtual meetup? Topics like:

- most liked features
- most annoying problems
- biggest missing features
- what would be the coolest/killer feature

Or another “ask VSCode and Juno developers anything” live stream.

---

<div class="post-metadata">

**Author:** ![davidanthoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/davidanthoff/32/223493_2.png) [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)\
**Post date:** [May 11, 2020, 10:16am UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/33 "2020-05-11T10:16:37Z")

</div>

I just created a new label `juno-parity` over at the [VS Code extension issue tracker](https://github.com/julia-vscode/julia-vscode/issues?q=is%3Aopen+is%3Aissue+label%3Ajuno-parity), and the idea would be that we have one issue with that label per feature that Juno currently has that is missing in the VS Code extension. And then we can start a discussion on each of these issues whether and how this could be added to the VS Code extension. I’m sure we need more issues, please open them!

> [@marius311](#):
>
> Stack traces highlighting lines of code included in the trace as red, for extra easy tracing of errors.

Could someone open an issue for this, ideally with a screenshot? I’m not 100% sure what this feature looks like in Juno.

> [@marius311](#):
>
> Entering debug for single statements within a running session

In the REPL you have `@enter` and `@run` to start debugging some code from the REPL, is that what you were looking for here?

> [@tk3369](#):
>
> How about a virtual meetup?

Yes, good idea!! I think maybe we take a bit more time to collect features etc., i.e. fill out the list I started over in the issue tracker, and then?

---

<div class="post-metadata">

**Author:** ![oschulz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oschulz/32/2998_2.png) [@oschulz](https://discourse.julialang.org/u/oschulz)\
**Post date:** [May 11, 2020, 12:01pm UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/34 "2020-05-11T12:01:34Z")

</div>

One feature of VS-code that I think is extremely relevant for scientific/technical computing is the excellent remote-development support it has now - and how well it is designed and how seamlessly it integrates with most extensions (especially the Julia extension 🙂 ). Atom just doesn’t have the infrastructure for this, internally (AFAIK) and that’s not likely to change - as @pfitzseb wrote, it seems like most Atom developers have moved on.

---

<div class="post-metadata">

**Author:** ![aviatesk](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aviatesk/32/7610_2.png) [@aviatesk](https://discourse.julialang.org/u/aviatesk)\
**Post date:** [May 11, 2020, 12:19pm UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/35 "2020-05-11T12:19:41Z")

</div>

We started [another thread](https://discourse.julialang.org/t/what-juno-features-do-you-use-most/39271) for collecting your ideas about what are the essential features of Juno, and whether/how we should move to VSC 🙂

---

<div class="post-metadata">

**Author:** ![Amin\_Yahyaabadi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/amin_yahyaabadi/32/9826_2.png) [@Amin\_Yahyaabadi](https://discourse.julialang.org/u/Amin_Yahyaabadi)\
**Post date:** [May 11, 2020, 12:41pm UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/36 "2020-05-11T12:41:01Z")

</div>

I personally emailed Atom and GitHub a while back about this (before Codespace announcement), but I have not gotten an answer yet.

There was also a similar discussion going on in the Atom forum.  
[https://discuss.atom.io/t/future-of-atom-github-codespaces/74460/2](https://discuss.atom.io/t/future-of-atom-github-codespaces/74460/2)

Regarding the move, I think that transferring Juno to VSCode is not that hard.

A lot of code is written in Juno just to make a REPL, connect to it, and get some data. In VSCode, this can be simplified using VSCode’s terminal and language server.

I was actually interested in helping with this, and I started with [making documentation for the VSCode organization](https://github.com/julia-vscode/LanguageServer.jl/pull/531). Settling down on the API of the Julia packages (e.g. LanguageServer, StaticLint) and documenting them is crucial for this. Otherwise, other developers should spend a lot of time studying the source code before they can use it.

cc: @davidanthoff @ZacLN  
[https://github.com/julia-vscode/CSTParser.jl/issues/130](https://github.com/julia-vscode/CSTParser.jl/issues/130)  
[https://github.com/julia-vscode/StaticLint.jl/issues/14](https://github.com/julia-vscode/StaticLint.jl/issues/14)

---

<div class="post-metadata">

**Author:** ![jlperla](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlperla/32/34332_2.png) [@jlperla](https://discourse.julialang.org/u/jlperla)\
**Post date:** [May 11, 2020, 2:57pm UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/37 "2020-05-11T14:57:28Z")

</div>

> [@marius311](#):
>
> Evaluate into current module and change module. I don’t think its been mentioned here but for me its critical for package developement to open some file which is included in some module and when I evaluate stuff in it, I’m evaluating in that module.

Yeah, that is the primary difference from workflow that is not cosmetic. It makes a big difference (and makes the brilliant, but pretty heavy, Revise an option instead of essential). Is there any fundamental reason that couldn’t be done as an optional setting in the existing vscode? It is so nice…

---

<div class="post-metadata">

**Author:** ![marius311](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/marius311/32/3953_2.png) [@marius311](https://discourse.julialang.org/u/marius311)\
**Post date:** [May 11, 2020, 6:53pm UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/38 "2020-05-11T18:53:41Z")

</div>

> [@davidanthoff](#):
>
> Could someone open an issue for this, ideally with a screenshot? I’m not 100% sure what this feature looks like in Juno.

@pfitzseb made one, as you saw: [Backtrace highlighting · Issue #1178 · julia-vscode/julia-vscode · GitHub](https://github.com/julia-vscode/julia-vscode/issues/1178)

> [@davidanthoff](#):
>
> In the REPL you have `@enter` and `@run` to start debugging some code from the REPL, is that what you were looking for here?

Had not found that but that’s exactly it, thanks! That certainly puts the debugging experience on very equal footing for me.

---

<div class="post-metadata">

**Author:** ![Marc.Cox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/marc.cox/32/7514_2.png) [@Marc.Cox](https://discourse.julialang.org/u/Marc.Cox)\
**Post date:** [May 12, 2020, 12:29am UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/39 "2020-05-12T00:29:33Z")

</div>

Hi @Tamas_Papp,

I basically agree its important to stay IDE-agnostic,  
especially considering the classic “Microsoft Way” being embrace, extend , then extinguish.  
I think it is VERY risky to trust large corps. to do anything they can’t make a buck on … eventually.

Also, Linux scales up - Windows doesn’t .  
Linux has little malware, Windows is crawling with it.

But on the plus side, Microsoft does get IDEs right sometimes … hmmm 🤔

---

<div class="post-metadata">

**Author:** ![imcinerney](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/imcinerney/32/9882_2.png) [@imcinerney](https://discourse.julialang.org/u/imcinerney)\
**Post date:** [May 12, 2020, 5:57pm UTC](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923/40 "2020-05-12T17:57:26Z")

</div>

Something that would be great is if the more IDE-agnostic parts of the Atom.jl package could be split out into their own packages for use by other IDEs. For instance, having a package that just implements the REPL-over-RPC environment would be great for other IDEs to be able to try to do better inline evaluation and display of results (for instance, that would probably allow for doing in-line results display with Sublime Text).

[Previous page](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923.md?page=1)

[Next page](https://discourse.julialang.org/t/github-annouced-codespace-does-it-mean-atom-is-now-abandoned/38923.md?page=3)