Any Julia only IDE available?

question

#1

I would like to know if there is any IDE that is designed specifically for Julia, I am more comfortable with IDE like RStudio, PyCharm, etc.

I think Julia should have its own IDE. I understand that some users write C++ and Python codes in Atom, but they have other choices. For Julia, it seems to me that Juno Atom is the only feasible choice now.


#2

it seems to me that Juno Atom is the only feasible choice now

There is no IDE specific to Julia, and honestly I think an argument can be made that a Julia-specific IDE isn’t necessary. However, there is Julia support in a lot of editors, such as emacs, vscode, sublime text, and others. I’d be interested in hearing what a Julia-only IDE could provide that’s not feasible in any of the alternatives.


#3

What about dataframe column name auto completion? Rstudio has it but not sure if it’s possible in Atom. Probably i guess.

The advantage of Atom is thr packages that come with it. There is a csv grid editor that Juno can leverage to show dataframes in grid form


#4

The Julia extension for Visual Studio Code has many great IDE-like features as well, e.g. auto completion, jump-to-definition, access to documentation.


#5

There’s was Julia Studio based on Qt early on but sadly it didn’t got a lot of support and got abandoned:

You have GtkIDE.jl, based on Gtk and written in Julia, but it doesn’t work on windows (should work on linux but I haven’t tested it for a long time):

Otherwise the Visual Studio Code extension is getting pretty good, but I’m still uncertain if it can really be as good as an native custom IDE in the long run.


#6

It would be helpful to know what you expect from “a native custom IDE” that you consider infeasible in, say, VS Code (not unimplemented, but infeasible — since we are talking about the long run).

Generally, maintaining custom tools for each language leads to a lot of duplicated effort. A lot of functionality can be shared, so it is easier to maintain common tools that are flexible enough to be customized for each language. Julia does this with its IDEs (VS Code, Atom, Emacs, …), compiler infrastructure (LLVM), plotting backends (GR, Plotly, …), and it is working out well.


#7

PyCharm is just the generic IntelliJ dressed up solely for Python at a lower price.


#8

I’m mostly uncertain because I don’t know much about web-based technology, and I haven’t seen yet a fully featured IDE for scientific work based on it. Arguably the last two efforts based on Atom and Light Table ran into some issues. But like I said it’s looking promising.


#9

PyCharm is succesfull editor/IDE written in java and specialised for python. If Julia is as superior as we think then future editors/IDEs (not only for python) have to be written in Julia. :stuck_out_tongue_winking_eye:

Good start to be there is making at least small steps now. There are known issues like that we need better language stability, making executable binaries easier, maturity of packages and debugging possibility to make Julia not only language for scientific recipes but also language for developers. (which could bring bigger manpower to support Julia!).

So what could change discussion like this? Maybe nothing. Maybe some roadmap, maybe some choices to not divide effort too much. For example support one graphic toolkit (maybe Gtk.jl?) could be good.


#10

This is a non-sequitur. Julia is a great language for scientific computing, and while it has some universally useful features (multiple dispatch, macros), it is not the best language for everything. This was never a claim.

Also, editors and IDEs for multiple languages are collaborative efforts between many language communities. Each of these considers their own language superior (that’s why they are using it), but insisting that shared tools are written in one’s favourite language would rule out this kind of cooperation by definition.

Most importantly, in open source it is pretty useless to exhort people about what they should be doing. If you truly think this is the way to go, start working on it (and realize what a monumental effort it is).


#11

Jonathan I was not able to make it run on Ubuntu 16.04 (nor 0.5 nor 0.6.1 nor 0.7.0DEV Julia works for me). Maybe problem with gtk library version? ((julia:15370): GtkSourceView-ERROR **: Error while loading the completion UI: .:23:106 Invalid object type 'GtkSourceCompletionInfo'). Maybe we could start other discussion thread (or issue on github… ).


#12

Tamas your cite is missing emoticon (and it change context)! I know that effort is monumental. And impossible without community. It is why people who think that IDE is good thing are trying to find it. And discuss about it before trying to do something wasteful.

And I know that it is also question about limited resources. Maybe it is good strategy to focus on scientific computing. (And maybe it is not)


#13

Can you elaborate, specifically as to what is missing in the existing IDEs (meaning VSCode and Juno as the two with most features) and what issues Juno has run into? Thanks! :slight_smile:


#14

Make an issue on github yes.

@pfitzseb I haven’t used either that much so I don’t have very specific issues, but having interactive plots for other backends than plotly would be great. Autocompletion also has some issues.

For Atom I think the main issues people have is performance, and that’s why VS Code seems now to be taking over. It looks like the ecosystem is still moving pretty fast.


#15

Interactive plots for other backends are coming to Juno - at least there’s a JavaScript terminal for GR under way.


#16

It would be great to have a “workspace” type window with all current variables and their types and dimensions displayed as well as an interactive dataframe viewer/editor. These are features that go beyond the standard programming language IDE but people coming from scientific computing (Matlab, RStudio,Spyder) who are excited about Julia would really miss these kinds of things for exploratory data analysis/debugging.


#17

Atom Juno does have a work space window. However in Julia, when you create a variable, it will stay in the work space and to my knowledge there is no elegant way to delete a variable in work space, this is quite different from R, Python, and Matlab.


#18

I’d strongly recommend looking at Juno’s documentation. There’s a lot of hidden gems. Did you know that Juno, apart from a workspace window that you need to open from the menu bar, also has:

  1. An in-editor profiler, that profiles your code and highlights how much time is spent on each code line – as bars overlaid on the code lines within the editor
  2. An inbuilt progress bar that can be called from your code
  3. A documentation browser that does fuzzy searching in all loaded packages or all installed packages
  4. A capacity to set the ‘active module’ of the file you’re modifying so you can use non-exported names
  5. An interface with Lint.jl that automatically highlights syntax errors in your code as you type it
  6. An inbuilt julia debugger based in ASTInterpreter2

? If not, you should check it all out.


#19

There are some plans to improve the Juno website to make those features more visible. We probably also have some tutorial built into Juno, but that’d probably be quite a lot of work which I don’t have time (or motiviation, tbh) for right now.

Also, small correction:

  1. An interface with Lint.jl that automatically highlights syntax errors in your code as you type it

That’s not actually built into Julia, but a separate Atom plugin. We do intend to use LanguageServer.jl in the future, which will bring non-Lint.jl linting (basically) for free.


#20

I’m currently working to disentangle the linting code so you should be able to hook it in if you don’t want to fully commit to using LanguageServer.jl