Is it inline evaluation (in a specified module), the remote execution capabilities, the profiler, or something else entirely?
Do you like how tightly coupled Juno is to runtime information, or do would you prefer us to
do more static analysis?
If you’ve tried the current VSCode-Julia extension as well: What Juno features do you miss most?
@marius311 has a great post on this here, but of course we’d love to read through as many different opinions as possible.
I’ve been mostly a Juno user (tried Sublime a few times, quite nice, a bit harder to set up) and I want to thank everyone who works/worked on it. These are my top pics, more from a user’s point of view, and less from a developer’s: Inline evaluation: I find it really useful to eval/update and see the result at the end of the line(with the option to expand the result or pin it). This applies for eval inside modules. I know we have Revise, but still I find this feature really useful. Debugger: Setting breakpoints with a click, all the navigation buttons, conditional breakpoints. Workspace: It’s good to be able to view the contents of some array, or “browse” through a struct with many subfields/structs. It even applies to simple stuff like checking if something is a tuple, instead of writing typeof(x) in the console. It’s also nice to have it when debugging, since it stacks the scopes that you’ve passed through. Documentation: This is a feature I haven’t used lately, but I saw big improvements in the discoverability of functions. One other cool thing is the “Go to definition” option. This can save a new user a lot of time, especially if he’s having a hard time understanding multiple dispatch and wondering which of the 5 methods with the same name is called in a package he’s not familiar with. Plots pane: It’s cool that in a lot of cases it just “knows” to display an object. It was a life saver for me in the beginning because ImageView on Windows was really slow (it still is, but improved a bit). Installation: It’s so easy to install(on Windows, don’t know about other platforms)
I know most of the stuff above can have workarounds and other people have other work styles, but Juno is interactive. All these things help lower the entry barrier for a new user.
Imho the most important feature of Juno is the inline evaluation, in a sense that it enables very interactive coding.
This feature consists of two parts; inline results and auto-module detection. Let’s describe what they give us in the two kinds of coding:
when scripting: we basically only need inline results, which enables Jupyter-notebook-like coding
when developing packages: Both automatic detection and inline results are tightly coupled, and enable an enhanced “REPL-based development”, which can be seen as an alternative of Revise
FWIW, here is my current understanding of how this feature will be like in VSC:
but it’s clealy not easy to implement auto-module detection in that interface, and so it’s likely we will lose Juno’s package development style. I won’t say it’s imporssible, but we need some dirty solution to implement inline evaluation in that interface at least, like converting each “block” in a script into Jupyter code cell, and vice versa. What we really need is something like what described in this issue, but I’m not sure when it gets into VSC.
Also a side note of Juno’s features based on static code analysis:
As an author of those features, I’m sure julia-vscode extension offers “better” support for that than us. They have never been in the core of Juno though, rather exist as “addons” on top of Juno’s runtime features. Combining both static and dynamic information, e.g. for a linter (, which actually we planned to do within the next few months) should give us something interesting, but it’s not implemented in Juno yet.
Thank you @pfitzseb for sharing this thoughts with us.
The inline evaluation is really great. The integration with the debugger and the ability to add breakpoints with mouse clicks are really nice, specially after we tick the “compiled mode” option in the debugger panel.
Moving forward, and as we discussed on Zulip, it would be really nice to see more notebook-like functionality where everything is displayed inline, including plots (like in a Jupyter notebook). The plot panel is useful, but I think many of us would benefit from a development workflow where we can see plots, html tables, images, etc. in place without having to navigate with arrows in the plot panel.
I didn’t had the chance to try out the integration with the profiler in Juno, but that is certainly a useful feature to migrate over to VScode if the migration ends up happening.
I just downloaded VSCode for the first time to get a sense of how it compares to Juno. I found it a bit disorientating and am sure I’m not doing it justice as there might be settings/fixes/workarounds I’m unaware of, but as a first impression:
Inline results is a big one, my Juno muscle memory made me think I didn’t actually execute my commands as I didn’t see any result pop up;
Related - it is odd to see that everything get copy/pasted into the REPL at the bottom
The plot pane is missing, which also means I can’t view tables through TableView in it (showtable just prints the html a string to the REPL) [EDIT: think I’ve worked this out by just splitting the workspace and keeping the plot open, new plots show up in that pane and I can cycle back and forth like in Juno!]
I can’t seem to get autocomplete on defined methods (e.g. typing showt in Juno would suggest showtable after using TableView, and then also provide suggestions for the available methods and the types they accept for each argument)
Overall, I was surprised to see that it seemed a lot more like a code editor and less like an IDE (in the mould of R Studio) compared to Juno.
Finally as someone who started using Juno when Mike first coded it up in LightTable I am also very attached to the Juno brand so hope the name survives
The cycler. I restart Julia fairly often when developing packages & wanting to make sure that things work as they should (no Revise is not enough), Juno makes this pretty quick + convenient keyboard shortcut. I might just not have found it but I recently gave VSCode a shot & killing and starting a Julia REPL was slow (again, very likely this is me not using the VSCode extension properly but I’m still grateful that Juno has this out of the box)
VSCode’s “Find definition” and linting suffer a lot from the static analysis (esp. for code defining/using macros), and could be a lot more accurate using runtime information instead of (or in addition to) static information.
I use Juno (with the weave extension) a lot for writing jmd files. The workflow of running chunks in the editor while I’m preparing the report, and then just click the “weave” button to make the html document is really smooth; it feels very like Rstudio for R.
Definetely. A lot of it is test-driven stuff where I mess around with a function in a package, edit code in the tests file where I see the output or see if I have a test passing, etc. The stuff Chris did in his test-driven development with Julia youtube.
In fact, I can’t think of any reason why I wouldn’t want the auto module detection.
To me these features are independent. The thing I like about the online results is often not the results themselves, but just to effectively see a flag if I executed the line of code or not. I can live without it for now.
Inline evaluation - very common pattern I follow: edit function, hit Ctrl-Enter, hop down a few lines to a line executing the function - hit Ctrl-Enter again, look at results, repeat.
Workspace - great to inspect values and structures of things.
Plot window - Look at plots.
Debugger - not regularly, but for certain problems (usually when I’m really confused) it’s great.
For what it’s worth, I actually much prefer sending code evaluation to the REPL rather than inline evaluation. For the short period when I tried Juno, I disabled inline evaluation. If inline evaluation were added to VS Code, I would definitely need an option to disable it.
To clarify, in VS Code you can hit Ctrl-Enter to send code to the REPL, and the cursor will automatically move to the next line in the editor, so you can just hit Ctrl-Enter again. In other words, the cursor focus stays on the editor.
I’m biased, because I created this, but check out Julia Color Themes for VS Code.
@pfitzseb First of all, thank you for the work you guys do with Juno. I am not a fan of Atom, but the Juno extension makes using it a very pleasant experience. (There are some development pain points in Julia, but those are independent of the IDE)
I think that the only thing preventing me from switching to VS Code is Inline evaluation. Absolute must-have. I don’se use the debugger much, but I feel like I should. Documentation I guess is also nice, and the Workspace or Plots are things that I can live without, but I would imagine other people find very valuable.
Thanks. I’m watching the Juno - VS Code discussions. Many months ago I compared them and decided I liked Juno better - but I can’t remember now what precisely was the kicker for me.
I should probably look at VS Code again especially as I have some coworkers who I may be convincing to learn Julia!
And I just got reminded of the red error highlighting: when you call a function that calls a function that calls a function that tries to modify the 5th element of a length 4 thing, you just scroll up looking at the highlighted red lines - much faster than reading the traceback.
