In a sadistic way, I’m kind of glad. Being a VS Code user, I always wondered if I was missing out on cool stuff with Juno. Now – no more regrets. I like options but I almost want them to disappear after I’ve made my choice! (competition is always good of course)
3 Likes
Of course not, but the entire experience does if you move to vscode for everything else. I prefer many of the features in Juno, but almost always use vscode for julia, just because I use it for latex and all my other work.
Furthermore, new users are much more likely to be either (1) using vscode; or (2) quickly figure out that Atom is a deadend… .
That is not necessarily true (in both theory and practice).
As soon as the payoffs are supermodular (or you could check complementarity with cross-derivatives), there are all sorts of places where competition can make things worse. This is especially true in models with network effects, which have high degrees of complementarity, and in two-sided markets (e.g. platform choice such as that of a editor).
3 Likes
Yes yes of course. But one can throw many wrinkles into the mix (heterogeneous preferences?). In this case, for example, many people probably still have a big dislike for Microsoft, so this could be a negative in their view. I also don’t disagree though that we might be better off if we all decided on a single IDE and focused our efforts there.
1 Like
I use Julia with VSCode and the most recent developments in VSCode Julia-extension make it competitive to Atom. Initially, I started with Atom, but it became very slow, and then I jumped to VSCode. I was wondering when Juno will move to VSCode. As now the discussion is also about switching Juno to VSCode, there may be one more option to consider.
Eclipse Theia (https://theia-ide.org/) is an opensource alternative to VSCode which brings foundation for both Desktop as well as cloud IDE. As far as I know, Visual Codespaces is not opensource. Theia also claims to be compatible with VSCode extensions (though not sure about the specifics). So building a Julia IDE around Theia keeps up with the opensource spirit.
Moreover, JuliaBox from Julia computing now provides only a notebook interface (?). My understanding from this is Julia Computing is ready to host a computing environment (of course, now, paid). But as Julia reaches more audience, it may be worth to host a complete cloud IDE also in JuliaBox to attract more customers. Since Theia has both Cloud as well as Desktop IDE capabilities, it makes more sense to have this unified solution. If both contributing volunteers and Julia computing can pool in, then the development can also be accelerated and we can soon have a working IDE.
16 Likes
I would be a bit cautious about this. As the example of Atom shows, IDEs can come and go in the span of a few years, depending on corporate backing and/or developers migrating to the next great project. (The only editors that have been around for decades are Emacs and Vi.)
Instead of picking a winner, I would advocate that IDE-related tooling is moved to (or kept in) packages that are IDE-agnostic to the extent possible, so that resources can be pooled between users/developers of various editors. A “thin” (
) layer can expose this to each IDE. This is of course already happening to a large extent — let’s just keep it this way.
29 Likes
I also wouldn’t call Atom “dead”. It’s open source. That means if people like it enough and the current masters are not giving it enough love, someone can always fork it and “take over.” Or the current master’s could give control to another group.
I suspect before that will happen though, it needs to “degrade” enough that someone get’s fed up and wants to take control.
2 Likes
This sounds very good idea. I’ve tried to list up what components are essential for Juno and whether they can be realized in VSC or not. AFAIU the features that makes Juno unique and powerful can’t be implemented in current VSC (like interaction with running session via inline results), but the thing is that VSC may be able to provide extension APIs for those features in the future. Maybe no one knows the estimate of that, but I’m sure David has more ideas on this than me.
As for the discussion on whether we should focus our efforts on a single IDE project, I rather want to say we should keep choices for various coding styles for programmers at least. vscode-julia extension offers very nice IDE features based on static code analysis (like what other IDEs do so) while Juno enables very interactive coding style (like Jupyter does). (so imho the current situation is not so bad in that sense) If it’s possible to realize those styles of coding style all in VSC, it would make sense to focus our efforts on that.
6 Likes
@aviatesk do you have that list somewhere? I’d be very interested to take a look. What is a good place to have these discussions for individual features?
My sense is that the one feature that really can’t be implemented with the current VS Code API is the inline viewing of eval results. MS had been working on an API for that, but it is unclear to me how much they are pushing that right now.
Having said that, we are getting a full notebook UI, which should make for a very Jupyter like experience. Obviously not exactly the same thing as the current Juno story, but I think it will make a big step for using the VS Code extension for interactive and explorative work. You can try the current (very buggy and incomplete) implementation over at Add notebook controller implementation by davidanthoff · Pull Request #980 · julia-vscode/julia-vscode · GitHub. You’ll need to use VS Code Insiders, and then just create an empty .jlnb file and open that.
I think the other major feature we are missing is a workspace viewer, but I’m pretty close to finishing an implementation for that at https://github.com/julia-vscode/julia-vscode/pull/1003.
Beyond that, I’m not sure what else in terms of major features is missing?
14 Likes
That’s why I use Vim or Emacs (with Evil mode) 
7 Likes
My 2c. I’m an Atom user but probably every six months I mess around with VSCode to see how far its come (the whole thing, not just the Julia part). I did this week too and this time I was really impressed. As someone constantly working on various HPC clusters, the remote workspaces alone is soooo good now and pretty much solidifies I’m going to move to all VSCode some time in the future.
That said, for Julia I will probably stick with Juno for now. FWIW, I think the minimal things that would get me to switch are:
-
Inline evaluations, both run-block (displays output on the side) and run-cell (displays output below, sort of like a notebook), with expandable “drill-down” outputs for both. Sounds like notebook-style displaying outputs below is coming to VSCode which is great, but unfortunately the run-block style is what I use more, because the outputs don’t expand anything to make space, so you don’t get visually disoriented of where the code is in your original file.
-
Evaluate into current module and change module. I don’t think its been mentioned here but for me its critical for package developement to open some file which is included in some module and when I evaluate stuff in it, I’m evaluating in that module.
Beyond that, there’s still a bunch of details which are really nicely polished in Juno that would be nice to have, including
- Profiler, especially including the thing Juno does where your lines of code get highlighted with a bar that has a length proportional to runtime.
- Stack traces highlighting lines of code included in the trace as red, for extra easy tracing of errors.
- Entering debug for single statements within a running session (in VSCode I could only figure out how to debug a whole file and also it always starts a new session? maybe I’m missing something though) and “Step to Next Expression”.
Anyway, that’s my perspective on it, ultimately both tools are very good and you guys all deserve alot of credit for the hard work you’ve put in.
41 Likes
+1 to all of marius311’s post. Those are my favorite Juno features as well (particularly the profiling and debugging integration into the editor pane)
3 Likes
How about a virtual meetup? Topics like:
- most liked features
- most annoying problems
- biggest missing features
- what would be the coolest/killer feature
Or another “ask VSCode and Juno developers anything” live stream.
4 Likes
I just created a new label juno-parity over at the VS Code extension issue tracker, and the idea would be that we have one issue with that label per feature that Juno currently has that is missing in the VS Code extension. And then we can start a discussion on each of these issues whether and how this could be added to the VS Code extension. I’m sure we need more issues, please open them!
Could someone open an issue for this, ideally with a screenshot? I’m not 100% sure what this feature looks like in Juno.
In the REPL you have @enter and @run to start debugging some code from the REPL, is that what you were looking for here?
Yes, good idea!! I think maybe we take a bit more time to collect features etc., i.e. fill out the list I started over in the issue tracker, and then?
14 Likes
One feature of VS-code that I think is extremely relevant for scientific/technical computing is the excellent remote-development support it has now - and how well it is designed and how seamlessly it integrates with most extensions (especially the Julia extension ). Atom just doesn’t have the infrastructure for this, internally (AFAIK) and that’s not likely to change - as @pfitzseb wrote, it seems like most Atom developers have moved on.
2 Likes
We started another thread for collecting your ideas about what are the essential features of Juno, and whether/how we should move to VSC
5 Likes
I personally emailed Atom and GitHub a while back about this (before Codespace announcement), but I have not gotten an answer yet.
There was also a similar discussion going on in the Atom forum.
https://discuss.atom.io/t/future-of-atom-github-codespaces/74460/2
Regarding the move, I think that transferring Juno to VSCode is not that hard.
A lot of code is written in Juno just to make a REPL, connect to it, and get some data. In VSCode, this can be simplified using VSCode’s terminal and language server.
I was actually interested in helping with this, and I started with making documentation for the VSCode organization. Settling down on the API of the Julia packages (e.g. LanguageServer, StaticLint) and documenting them is crucial for this. Otherwise, other developers should spend a lot of time studying the source code before they can use it.
cc: @davidanthoff @ZacLN
https://github.com/julia-vscode/CSTParser.jl/issues/130
https://github.com/julia-vscode/StaticLint.jl/issues/14
5 Likes
Yeah, that is the primary difference from workflow that is not cosmetic. It makes a big difference (and makes the brilliant, but pretty heavy, Revise an option instead of essential). Is there any fundamental reason that couldn’t be done as an optional setting in the existing vscode? It is so nice…
@pfitzseb made one, as you saw: Backtrace highlighting · Issue #1178 · julia-vscode/julia-vscode · GitHub
Had not found that but that’s exactly it, thanks! That certainly puts the debugging experience on very equal footing for me.
2 Likes
Hi @Tamas_Papp,
I basically agree its important to stay IDE-agnostic,
especially considering the classic “Microsoft Way” being embrace, extend , then extinguish.
I think it is VERY risky to trust large corps. to do anything they can’t make a buck on … eventually.
Also, Linux scales up - Windows doesn’t .
Linux has little malware, Windows is crawling with it.
But on the plus side, Microsoft does get IDEs right sometimes … hmmm 
4 Likes
Something that would be great is if the more IDE-agnostic parts of the Atom.jl package could be split out into their own packages for use by other IDEs. For instance, having a package that just implements the REPL-over-RPC environment would be great for other IDEs to be able to try to do better inline evaluation and display of results (for instance, that would probably allow for doing in-line results display with Sublime Text).
3 Likes