JetBrains also makes IntelliJ IDEA which fully supports the Julia plugin. I’ve been using it for months without problem. IntelliJ is a good development environment which I’ve enjoyed using. However, Juno has become my recent favorite as I find it a bit simpler to use. In both cases, I wish the Outline pane would recursively descend into functions and macros, showing local objects declared within them. PyCharm does this with Python code and I find it an excellent way to noodle through things.
What about the repl? I could not get the repl to behave: the package, shell, and help mode wouldn’t work.
Here’s a screen shot of a session I just ran with some trivial test code. As you can see, the REPL functioned perfectly.
I can’t see that this shows the repl modes working, sorry.
BTW, users of Spyder 5 may have the choice of Julia as one of the supported languages.
1 Like
Here’s a session with explicit use of REPL. Text running off the top of the image are the end of output from include(“test_constant.jl”). Entered expressions, such as the examples following the output, are not processed unless the shift key is held when pressing return:
Sorry, I was being unclear. I meant that the shell, package, and help modes were not working. You know: ?size, ]add DelimitedFiles, etc.
Hmm. This appears different from what I see:
Notice the panel-like single line at the bottom, which is the only place I can type in.
I am new to Julia, having moved to it from Matlab and R. Maybe I still have a lot to learn, but I have never liked Atom and think VS Code could be a good replacement. Average Joe programmers like me are influenced a lot by the design of menus and screen layout options, which in my view have only received scant attention in Atom. But then I must confess to being a two finger typist hooked on ‘point and click’ from from the distant past.
After almost fifty years of programming experience in many languages, I have only recently discovered the concept of literate programming, the use of Julia Markdown for this, and am really hooked on it. So, when making the change, I would advocate that you make sure that it and associated tools are seamlessly integrated with VS Code. Some of the following features, if they do not already exist, would be most helpful:
-
A toggle to comment out multiple lines of code like in R Studio.
-
Inclusion of the Julia Markdown Outline feature currently installable in Atom.
-
The capacity to undock panes to make use of multiple monitors.
-
A pane to display the Julia workspace (ie. variables, functions and values).like in JUNO.
-
The capacity to run all code preceding a particular point in the jmd document as is currently possible in R Studio.
-
The capacity to terminate a runaway computer run.
-
Modify the now excellent debugger to provide “Run Block” rather than “Run File” as the default option when using Julia Markdown.
3 Likes
Thanks everyone for your feedback!
Going forward we’ll support Juno (and supply critical bugfixes), but will focus our development efforts on getting the VSCode extension to feature-parity.
36 Likes
This is available, shift-cmd/ctrl-7. cmd on macs, and I suppose ctrl on win/unix. It’s actually not a Julia-specific thing, but toggles comments in all languages. It’s also the same for VS Code, Atom and SublimeText as far as I know.
Can you point to something missing in Atom that you need to take this path?
Namely, why should you care if Atom is developed or not as long as it is a good driver for the Julia Extension (Juno as a whole)?
There are advantages in having 2 parallel efforts.
1 Like
Usually I’d agree with this sort of thing but Atom development has been increasingly slow for several years. The point of utilizing something like Atom is to avoid personally managing development of stuff like bugs due Electron updates and other stuff not related to Julia. I bet several years from now using Atom as the basis of Juno would require just that.
1 Like
Are you really serious about this question? While both Juno and Atom are fine, or more than fine, at the moment, you have to be able to extrapolate into the future. Atom is clearly being abandoned in favour of VS Code. Continuing to focus efforts into Atom would be the very definition of a dead end.
Put another way: if Atom is fine, and Juno is fine, neither one needs further development. You could just keep using both in their current state, in perpetuity, right?
3 Likes
Juno is clearly not complete.
But both Juno (As the set of all extensions to Atom) and VS Code Extensions are extensions of a driver.
If the driver has no issues and provide all needed to fulfill the needs of the extension, why would one care if the driver is developed or not?
I can see the reasoning if there are issues which prevents the driver to supply needed features and they are on the road map yet since development is ceased it is a problem.
@Zach_Christensen, Are there blocking issues with Atom? Are there issues which prevents farther development?
In my point of view, for extension, if the driver provides all needed and is reliable without any major issues it is a valid driver. Whether it is being maintained or nor.
I’m not the one to ask if there are currently issues with Atom that would prevent further development of Juno because I don’t develop Juno. However, important improvements to Atom that people may want just aren’t going to happen (e.g., GitHub - atom-archive/xray: An experimental next-generation Electron-based text editor was abandoned a while ago).
I really don’t get this part. Everything takes maintenance, especially something with lots of dependencies like Atom.
The writing has been on the wall for Atom for a long time now and I think that’s kind of the point of this thread. Now that we need to start transitioning to something else how can we do so in a way that’s is the least disruptive to everyone’s workflow?
2 Likes
Could you recommend a tutorial for Julia VS Code?
There are some good ones for Juno, but I could not find one for VS Code yet.
5 Likes
Answering the original question: the variable panel, the debugger, the profiler and the inline output.
If only would be stable and fast, Juno would be by far the most productive IDE of any language I did use.
7 Likes
an update after messing with VSCode for larger simulations - I can’t interrupt certain while loops, which to me means I’m sticking with Juno until that gets sorted out.
edit:: as @ToucheSir pointed out, it’s not too hard to avoid this by putting loops in functions.