Are you really serious about this question? While both Juno and Atom are fine, or more than fine, at the moment, you have to be able to extrapolate into the future. Atom is clearly being abandoned in favour of VS Code. Continuing to focus efforts into Atom would be the very definition of a dead end.
Put another way: if Atom is fine, and Juno is fine, neither one needs further development. You could just keep using both in their current state, in perpetuity, right?
Juno is clearly not complete.
But both Juno (As the set of all extensions to Atom) and VS Code Extensions are extensions of a driver.
If the driver has no issues and provide all needed to fulfill the needs of the extension, why would one care if the driver is developed or not?
I can see the reasoning if there are issues which prevents the driver to supply needed features and they are on the road map yet since development is ceased it is a problem.
@Zach_Christensen, Are there blocking issues with Atom? Are there issues which prevents farther development?
In my point of view, for extension, if the driver provides all needed and is reliable without any major issues it is a valid driver. Whether it is being maintained or nor.
I’m not the one to ask if there are currently issues with Atom that would prevent further development of Juno because I don’t develop Juno. However, important improvements to Atom that people may want just aren’t going to happen (e.g., https://github.com/atom-archive/xray was abandoned a while ago).
I really don’t get this part. Everything takes maintenance, especially something with lots of dependencies like Atom.
The writing has been on the wall for Atom for a long time now and I think that’s kind of the point of this thread. Now that we need to start transitioning to something else how can we do so in a way that’s is the least disruptive to everyone’s workflow?
Are you able to extract the loops into functions? Anything invoked with Ctrl + Enter (“Julia: Execute Code”) can be interrupted without issue, but evaluating code cells, blocks and files uses a different code path in the extension. Because of this, my workaround is to create something like a train_loop (for ML stuff) and Ctrl + Enter a one-line call to that function.
Very late to this party. @pfitzseb, you’re definitely making a difficult but correct decision. Living code will always win in the long run.
Currently I constantly switch among Juno, VSCode, and emacs. First let me discuss the “editor” component, not something that the Julia community itself provides. As an editor, on balance I do like VSCode better than Atom: personally I appreciate its slightly-better multiple-cursor support (a feature I use heavily), its text-rendering (it somehow looks crisper), its ability to pack a lot of functionality in small dialogs (Atom’s search/replace dialog seems more intrusive, screen-space-wise, while being less useful than VSCode’s), its speed, and its navigation pane at the right (showing the miniature rendering of the buffer). On balance I think you stand to win by moving to VSCode. The one Atom feature I desperately miss in VSCode is Atom’s beautiful git/github extension; I have not shopped around but the default one in VSCode, despite having a couple of nice features, is not in the same league.
As for the Julia community’s contributions. Juno itself brings so many nice goodies. Most of the things I like have been mentioned above; among many, I will emphasize the quality of Juno’s debugger support as something I especially admire. I should also say that Revise might change in ways that will make the inline evaluation even more useful (discussion ongoing at https://github.com/timholy/Revise.jl/pull/497).But I really want to add two new things:
Juno’s documentation is excellent, and really helps with adoption
Some people in my lab rely utterly on the remote-editing feature, and because I haven’t looked I don’t know whether that works in VSCode
VSCode’s Julia extension adds different goodies. I do like the LanguageServer-based navigate-to-definition and miss that when I’m in Juno (If it should work, it never has for me). The linter is getting better all the time and something I increasingly get benefit from.
Overall I am very excited at the prospect of the two IDE teams joining forces. In some ways the real strengths of the two IDEs are almost orthogonal, so I can imagine that the combination will be a force to be reckoned with! Kudos to you for taking these steps and bringing such ongoing awesomeness to the Julia community!
At least in theory the debugging experience should be fairly similar at this point between Juno and VS Code? I think the one feature we don’t have in the VS Code debugger is a fine grained stepping command for multiple instructions on one line (but support for that is improving in the next version of VS Code that should ship in about a week), other than that I’m not aware of any missing features. If there are, please open an issue over at https://github.com/julia-vscode/julia-vscode, we’re trying to come up with a complete list of things that are missing on the VS Code side for feature parity with Juno. We don’t have docs for the debugger, the next best thing is my announcement at [ANN] VS Code extension v0.15 released - with debugger and the generic VS Code debugging docs.
I think that is probably the area where VS Code is strongest, IMO. Take a look at the remote documentation.
From my point of view, there are two or three things that make the debugger experience in Juno better. I’m not opening issues in the VS Code extension repo because I think they would overlap with existing issues or PRs (but let me know if I’m wrong and they should be opened):
I like using the REPL in debug> mode, instead of having to switch to the Debug Console. It is more consistent with the experience of using other debugging tools like Infiltrator.jl, or Debugger.jl (You may not need Debugger.jl if you are using the visual debugger, but at least Infiltrator is a good complement.) Besides, the messages in the REPL are kept once the debugging has finished, but not in the VS Code Debug Console. However, maybe this is not meant to be changed, because it is the usual “VS Code way” of debugging. Or maybe it is covered in https://github.com/julia-vscode/julia-vscode/issues/1047
Not sure about this, but while in general Julia runs faster on VS Code than on Atom, I have the sensation that in the particular case of the debugger it is the other way round. Maybe this is not real, only the consequence of having tried it with different cases in one case and another.
On the other hand, I must say that the possibility of “watching” variables or calcuations on those variables in VS Code is very nice - although I’m not using it much because I have learnt use Juno’s debugger without that feature.
While I really like the experience of this in general, I have not found a way to make sessions persist through disconnect. Atoms use of tmux means that I can start a process, walk away and let my computer sleep (which interrupts my VPN and disconnects me), then come back when my process is done and reconnect. VSCode remote doesn’t seem to work like that.
I agree you’ve made enormous progress, but https://github.com/julia-vscode/julia-vscode/issues/1091 all by itself is essentially a showstopper for me. If you can direct me to how to replicate the mechanism VSCode uses to interact with CodeTracking (I’ve subscribed to that issue so you can just comment there) I can help think about how to solve it.
A work around for this problem, for anyone who hasn’t yet arrived at this solution themselves, is that you can just directly use tmux inside the terminal of a remote vscode session to persist the state of your terminals. I have an extension for VSCode that makes this a tiny bit easier, though it does not yet play well with the julia extension (terminals opened through the extension do not “connect” to the julia extension, which means some of the cooler features of VSCode in julia do not yet work).
Is this more reliable than connecting to an eternal terminal forwarded connection? This is a feature I love in Juno and I imagine quite useful for people coding on their laptops connected to powerful remote machines…
I’ve never used that feature of Juno, so I can’t say. Both tmux and screen are old reliable open source solutions to maintaining a running terminal over ssh. I’ve just created a simple way to associate a given vscode workspace and REPL with a tmux or screen session. The scenario you describe is exactly the motivation: vscode already stores the state of the workspace for remote sessions using its ssh remote extension and my extension uses tmux or screen to save the terminal state (with either remote or local workspaces).