an update after messing with VSCode for larger simulations - I can’t interrupt certain while loops, which to me means I’m sticking with Juno until that gets sorted out.
edit:: as @ToucheSir pointed out, it’s not too hard to avoid this by putting loops in functions.
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.
That’s nice to know!
I can encapsulate loops in functions, but for experimentation and debugging I usually don’t so that variables dump into the REPL workspace. Still, that’s helpful for if (or when) I go back to VSCode.
Then, further suggestions of current Juno features that we would like to see in VS Code should still be reported here, or is it better to file them in the julia-vscode issue tracker?
Sorry if this has been mentioned before, but previews for unicode symbols are super helpful.
Juno:
VSCode:
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 RFC: Revise 3.0, rewrite based on LoweredCodeUtils.CodeEdges by timholy · Pull Request #497 · timholy/Revise.jl · GitHub).But I really want to add two new things:
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 GitHub - julia-vscode/julia-vscode: Julia extension for Visual Studio Code, 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.
Agreed with everything else you wrote 
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):
The “Workspace” pane that shows all the variables in the current scope, not only the local ones – and in the case of nested functions, all nested scopes are shown. This might be covered in https://github.com/julia-vscode/julia-vscode/pull/1003
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 Debugger ignores Revised code or code edits · Issue #1091 · julia-vscode/julia-vscode · GitHub 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.
Everyone who is interested in this feature, please upvote Persistent SSH session · Issue #3096 · microsoft/vscode-remote-release · GitHub!
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).
You may want to look at GitLens. I rather like it.
Revising my old statements - having learned over the last week how to read flame graphs, the most useful thing in Juno is the @profiler integration.
For the example you’re showing, have you tried
u .+= rand.()
v .= rand.()
?
This should avoid the unnecessary allocation of using rand(10).
Oh, yeah - this was just a demo to illustrate immutability of tuples to a student.
You can never unmolested post sub-optimal code here, you know 