I switched from juno to vs code for julia development a little over a year ago, not for IDE features but because I preferred it as an editor and I liked the static linting and the git integration. However, I still keep an up to date atom/juno installation for the profiler. It’s a really great way to visualize profiling results and the ability to click on an entry in the graph and have it direct you to the relevant source code line is super convenient.
I like the remote REPL. I have a server with a nice GPU that I can use from my laptop.
I love Juno/
My favorite feature is inline evaluation.
Also: red error highlighting, debugger integration, profiler
I never tried VS code.
The main IDE features I dream of:
- a plots pane that easily allows saving plots w/ a click
- a package pane that easily allows me to see which packages are in my environment & whether my package is latest …
- a files pane where I can easily move around directories & load data & gen code w/ a click
- the ability to “pop out” my editor to a new window
I hope these features will be possible in VS Code.
+1 for:
- Inline evaluation
- Workspace
Just switched to VSCode from Atom/Juno. VSCode has been nice so far, and it seems like it’ll be a pretty smooth transition. A few things I miss from Atom/Juno
- the fast REPL restart (cycling) mentioned by @tlienart
- plots scaling to window that @jonniedie mentioned
- being able to magnify plots (doesn’t change the resolution, but is still convenient). may be addressed soon?
- plots opening in a new window or separate pane
@pfitzseb is it possible for Juno to move to RStudio?
Bc RStudio now allows Python code: RStudio: A Single Home for R & Python - RStudio
Do you prefer to have Julia be a second-class citizen in RStudio than trying to get something focused on Julia? I’m not an expert in Python, but when I tried to use RStudio for Python, it didn’t seem like a nice experience. RStudio is nice because they know exactly the users they wanted, notice how almost nobody with a hardcore CS background uses RStudio and stay with their vim, emacs and such…
@alejandromerchan I fully agree that Python is not great in RStudio.
It doesn’t mean Julia can’t be optimized to make better use of RStudio. That could save the Juno developers A LOT of work.
You gotta admit the RStudio interface is much friendlier to data people.
But yea, we’d probably lose some of the cool features from Juno like inline eval…
there is no easy answer…
I suspect that moving to Rstudio would push away a lot of people. VS Code seems to have a much broader target audience, and supports general editing features better. It’s also much more similar to Atom, I think.
Maybe some of the ‘editor agnostic’ features could be used to make a separate Rstudio plug in, though.
Just a few comments. Overall both extensions are really good! Great work.
Inline evaluation, with the ability to re-evaluate a function definition with some changes inside a package (say) and have it picked up instantly in the current session. This allows a very nice workflow in Juno that would be nice to have in vs-code too.
The profiler is VERY useful! Seeing the execution time plotted right on top of the code is very informative. So please bring it to vs-code too. One minor suggestion is that I would like be able to “filter out” calls that go outside the package I’m developing (say) from the flame graph.
Improve the debugger (e.g., inline evaluations in debug mode sometimes don’t hit breakpoints, and allow us to set new breakpoints dynamically during a debug session).
One quirk in Juno is that when I terminate a Julia session, the breakpoints disappear. I think they should stay placed.
The auto-completion seems to be more aggressive in Juno than in vs-code, and I like it. Maybe the same behavior can be ported to vs-code.
I really miss a simple thing: shortcuts to be able to evaluate code blocks and cells while not advancing the cursor to the next one.
Shortcuts to move between cells would also be nice (but no showstopper).
A feature that I’m missing in VSCode, because I personally requested it from Sebastian in Juno, is the visual cell indicator for executing code. I think it’s a pretty bad user interface to not have any real visual indicator for the code that will be executed in block or cell mode. It happens to me very often that more code than I wanted is executed because I misjudge what counts as a block or because I forgot to set a ## cell delimiter correctly. I think for the current cursor position there should always be a subtle, unintrusive indicator of the code that would be executed in cell mode (maybe a slightly different shade for the whole selected code cell) or in block mode (maybe a thin vertical line on the left spanning the affected lines)
There is actually already an issue for this: Highlight currently active code cell and / or code block · Issue #961 · julia-vscode/julia-vscode · GitHub You can +1 it with a thumbs up (I already did.)
I made that issue 
Hehe. I once found an answer to a question (I think it was on Stackoverflow), and realized, only after thinking ‘that was a really good answer’, that it was I who had written it myself a year before…
inline evaluation
Debug: Step through File
About vs code: just tried it and it seems nice in several ways, but copying the whole file to the REPL looked awkward.
In general: I believe a Julia IDE should (at least initially) target new users and keep it simple.
I’ve been using both VSCode Julia and Atom Juno for a while. Both are great, and the recent advances in visual debugger in both just made Julia much more accessible to a wider audience. However, in my opinion VSCode just provides a smoother overall experience with less surprises.
The biggest things I miss from Atom Juno in the order of most desired first:
- Intellisense for local modules introduced by “using”. (There is an open issue in the repo already.)
- Workspace.
- Visual profiler. (This is coming soon once Microsoft publishes a visual profiler for VSCode.).
- Cycler to reboot Julia quickly.
- A toolbar and/or some buttons for Julia specifically.
In addition, I think the following feature neither has could SIGNIFICANTLY improve the experience of those who use debugger frequently:
- Automatic switching between the compiled mode (for fast execution) and the interpreted mode (for catching breakpoints inside layers of functions).
A couple nice-to-have features that neither has right now:
- An easy way to save and reload a workspace (either just the data, or data plus modules/functions/types).
- An easy way (e.g. a command or button with some settings) to use PackageCompiler to build a custom image and/or app easily, and a setting to load that custom image with a fall back of the standard image.
For me the killer feature of Juno is the visual profiler. The debugger integration is very convenient, too. I’ve never even explored ways to use these tools outside of Juno.
I don’t really care about interactive evaluation in Juno as I tend to use a Jupyter notebook for exploratory/documentary stuff. For developing reusable code I’m already used to a REPL+Revise.jl+editor workflow.
Well, pardon me doing it the other way around this time, but it must be noted that Vscode-julia also has some killer features. I’ll tell something I really miss in Juno, which exists and is great in Vscode-julia: automatically using the environment of the Project.yaml of the current folder.