I’m quite new to Julia. I’ve tried Juno in the last couple of days – because it’s certainly well advertised on Julia’s main homepage. I absolutely love it! However, it says somewhere
Attention : We have decided to join forces with the Julia extension for VSCode. As such, this Atom-based plugin is effectively in “maintenance-only mode” and we expect to only work on bug fixes in the future.
And now i’ve found a discussion on “discourse”, from May 2020, which seems to indicate that indeed, everybody is moving to vscode now.
My experience with Juno was great, but of course I’m not addicted to it yet… should I try vscode instead, because Juno is about to die? How have things evolved since May 2020?
Juno is still presented as the IDE of choice on Julia’s main page, cf the “JuliaPro” bundle. It would be weird to drive people in the direction of a project that’s about to be abandoned. And yet, if Juno and vscode are sufficiently similar, I might as well go with the long-term solution.
Juno is definitely still usable, but there won’t be any new features and only fixes for critical bugs. So you’re definitely welcome to keep using it (as are many people), but I would recommend moving to VSCode for a couple of reasons:
It’s the (arguably) better editor and actively developed.
The Julia extension is (mostly) at feature parity with Juno (although sometimes a bit rough around the edges still) and actively developed.
You won’t get into any weird situations with package version incompatibilities with the VSCode extension as is likely with Juno, which can cause hard to track down (or just very annoying and impossible to fix) bugs.
Regarding JuliaPro: The whole product is being phased out, so that’s not really an argument towards Juno’s longevity or future.
Thanks for your replies. I guess it makes sense to turn to vscode. I feel very funny about using a microsoft product – brings back memories of my teenage years fiddling with autoexec.bat. I remember not being very impressed by them. Perhaps they have improved in the meanwhile!
Related, I recently fell down the Juno rabbit hole after seeing it recommended at Profiling · The Julia Language. I was confused at first because I had heard that Juno is migrating to be based on vscode (which is accurate; it’s just that this combination is no longer called Juno). My confusion was not resolved until I realized that both https://junolab.org/ and https://www.julia-vscode.org/ are obviously divergent forks of the same website. Still, there is no mention on either site of how they relate to each other. And it’s unclear from the profiling documentation whether there is support for profile visualization in julia-vscode, just like there is in Juno.
I just installed VSCode because of Juno becoming deprecated… It is clunky, sad and brutal to properly debug using the REPL. You can’t customize the layout… I lament Juno and hope they change their mind about deprecating the better tool.
I wholeheartedly agree with this (my main gripe is that VSCode is not as tighly coupled with the running Julia process, which means tab completion becomes much less powerful, especially hitting DataFrame workflows hard - but that’s a very fundamental design decision) BUT it should be said that the choice was a bit forced onto the Juno team as Microsoft basically pulled the plug on Atom when they acquired GitHub, so unfortunately there’s a high risk of investing in a dead end with any work put into an Atom plugin.
An other one here… I know, changing the system you are used for with a new one is always a pain, and I understand it is frustrating to get users telling you “I want back the old system that is better” even if actually the new system has many benefits the user hasn’t yet realised.
That said, I am now in the “user” seat.
There are tons of small things that I miss in Juno :-/
A few in the list (not ordered by importance)
the apparences, from the font/colour to the layout organisation/personalisation
post-command (alt-enter) hoover:
can not be closed nor expanded as in Juno
the full output is reported rather than just a “smart” summary as in Juno:
its value is printed in the console, while I would prefer keep the terminal clean (ok, this can be changed with a setting option, but it is not default)
the drop-down suggestions for the unicode symbols don’t contain the symbols themselves (and the backslash is of the same colour than the unicode name):
Also the proposed (matched) unicode symbol shoudn’t be shown with the leading backslash
Ok I stop here… all this just to say that while VSCode is undoubtedly more technically advanced, it is still far from the neatness reached by the old Juno, so maybe promote it as the default IDE may still alienate new users
Those are all good points I think many can agree with. Tbh I didn’t like Atom much, but the Juno extension to as really good so I guess we have to wait and pray they add at least some of it to the Vs code extension.
So, in anticipation of moving to VS Code sooner or later, I finally installed it.
Using @time begin ... end
framework, I measured the execution time of one of my pretty standard codes that uses several packages to run. In Julia 1.6.3, for four attempts in Atom with Juno 0.12.6 it was respectively: 49, 24, 32 and 24 seconds, while in VS Code with Julia 1.4.3 extension it was respectively: 60, 36, 37 and 36 seconds. I am pretty surprised that VS Code turned out to be significantly slower, especially on the first run. What are your comparison experiences, guys?
I would prefer not to disclose the code as it’s an early-stage research project code. But if it matters, in the code that I used for comparison, I am using Interpolations, Plots, Parameters, Random, BenchmarkTools, JLD, Statistics, DataFrames, GLM packages.
As it happens, I don’t have many codes at all, especially with these packages, as I’m still pretty new to the language. Figuring out exactly which one of the packages might be the source of the discrepancy in codes runtime would take to much of my time right now, but if you think about any one specific package that might be the source of the problem, I can try running the code with it in both editors.
Since it’s really Julia, not VS Code or Atom that should determine the runtime, I wonder what sort of overhead you are seeing. Are you observing the Performance Tips · The Julia Language ? And, in particular, are you making sure to put your code in functions and avoiding global variables?
And are you using the same package versions in both cases?
Yes, in general, I try to observe most of the performance tips.
I though that maybe the packages differ on the two editors, but once I updated them on VSC, which I installed recently, they seemed to be already updated also on Atom (I, therefore, guess that the packages are more related to Julia itself rather than to any editor). Anyway, I rerun the test and the results are again better in Atom, although without first-run advantage: Atom - 61, 22, 22, 33 seconds, VCS - 61, 37, 36, 36 seconds.
