Julia’s IDE integration with Atom through Juno is superb. It seems that a lot of effort has been put into Juno to make the Julia experience first-class in Atom.
With that said, Visual Studio Code has come along way, and surpassed Atom in community, support and performance for some time. It’s an editor of choice for some languages such as JavaScript, Go, Typescript and others.
When I come to the Julia community I scratch my head and wonder why Atom is still being used. I suspect, in part, the reason is historical. At the time a choice, there was probably less distinction between Atom and Visual Studio Code. Yes, there is a VSCode extension for Julia, and it is good, and getting better, as is Juno. And, there doesn’t need to be just one IDE.
Would there be some benefits to evaluate investing in VSCode instead of Atom? Are there further reasons to continue to maintain Juno beyond momentum?
The window system is much more flexible, so a lot of the inline results and progress bar stuff was only really doable in Atom. IIRC That has only in the last few months been changed with VSCode? That’s a question for @davidanthoff, but that’s really been the big deal since those tree views are pretty essential for some applications (like differential equations where the nesting can get quite deep). Recently TreeViews.jl was sectioned off, so a REPL-based version of treeview outputs could be made, and then with new windows etc. VSCode could get what Juno has.
But in some sense, the two have had somewhat of a different focus. With DifferentialEquations.jl I decided to start using Juno in Atom almost the day it came out (before that it was LightTable), so now there’s been about 4 years of issues, discussions, and PRs that make it great to use with DifferentialEquations. That’s hard to match, though over time as VSCode adopts those features it’ll start to feel similar. Similarly, given the developer’s other focuses, I’m sure VSCode has some nifty stuff for data science.
I think adding progress reporting to VS Code would be feasible at this point, I’m pretty sure there are enough UI hooks to do that.
Inline results can’t be done today. The VS Code team had been working on something where one could show custom stuff between code lines, but I’m not sure whether that is going to ship anytime soon.
We will be getting a workspace view in the VS Code extension soon ™, and it will have tree drill down into composite types. It won’t use TreeViews.jl, but just be based on standard Julia type logic (i.e. you’ll be able to drill down into composite types, arrays and dicts).
But before we ship that, we’re going to ship a debugger in VS Code (which, btw. also has tree drill down during debugging).
I’m probably most excited about the notebook UI that is coming to VS Code. The core VS Code team is adding UI for notebooks, and then extensions can provide their own implementations for different backends. I’m pretty sure someone will build a Jupyter notebook extension. I plan to add support for “Julia Notebooks” that will mimic R Notebooks from RStudio (in particular in terms of file format).
As Chris points out above, Atom allows extensions to do literally anything they want, which has the obvious advantage that Juno can add all sorts of fancy UI elements and the downside of having to be really careful to not break or slow down the editor itself.
Also, don’t underestimate “momentum” – Juno has been available in Atom ~2 months (August 2015) after Atom’s first release and I’d expect many people to be used to the Atom workflow/environment by now
That said, I somewhat expect that we’ll move Juno to VSCode at some point (be it by contributing to the current VSCode extension or by building something new).
Sorry to derail this thread, but why not use TreeViews for this? I’m not super happy with the API either, but the idea of having a customizable structured display is very important imho.
Note that these decisions are not centralized — people usually just like using an IDE, and then contribute to making it work with Julia. At the moment, Atom/Juno, VSCode, and Vim are actively supported, and some other IDEs are WIP.
I have to say I really hope that doesn’t happen. I think having two Julia extensions for VS Code seems like a super confusing situation for users and an incredibly inefficient way to use the scarce dev resources we have. What would be arguments for such a move?
We generally try to not rely on any packages in the REPL process. We generally consider the REPL process as owned by the user, not us, so we don’t want to load any package into the user/REPL process to avoid any package versioning conflicts with stuff that the user might have/want to load. There are some ways around that, but they are complicated and at least for a first version I’d like to avoid them.
I think I’m also not 100% sold that in general it would be good to be able to “hide” the actual structure of the types one is using, as a user I probably just want to be able to explore whatever structure the types that show actually have? But I’m not super familiar with the tree drill down in Juno, so should probably look more into that. Are there some key examples of custom drill down behavior of some types that are sort of canonical why that is so useful?
I guess my final thought on this is that if we were to offer customization of display options, I would try to see whether one can do that via some custom MIME type solution, rather than introduce new types in a shared package.
I’m quite fond of the work @davidanthoff has done on VS Code, and with VS Code itself. I switched from Atom/Juno to VS Code about a year ago and I am extremely happy with the switch. Atom felt really clumsy and slow to me, and I am constantly worried that it will die the slow death that comes with having a competing in-house product at Microsoft.
For whatever “resources” (high-fives?) there are available, I’d be interested in throwing them over to David and his excellent work on VS Code.
Here, you know what, I have a spare high-five anyway: . Great work, I love VS Code and the Julia support.
I’ll take the high-fives, but I do want to point out that the VS Code extension stuff is really a two-person effort between @ZacLN and myself. I might be slightly more visible in the community because I tend to make the announcements, but all the really difficult work on the underlying language server was mostly done by Zac
I also like the recent versions of the vscode julia plugin and as I understand it more nice things are to come.
So more high fives from me for @ZacLN and @davidanthoff:
Another from me. I love VS Code. I always have like 20 projects open at any one time because why bother close and reopen them when VS Code is so fast anyways
The addition of the debugger is fantastic news. Thank you @ZacLN and @davidanthoff for your amazing work! Know that you’re making a huge difference for so many people!
. Great work, I love VS Code and the Julia support.
