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.
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.
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.
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.
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.
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.
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.
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.
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).
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ā¦ ).
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)
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!
@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.
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.
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.
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:
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
An inbuilt progress bar that can be called from your code
A documentation browser that does fuzzy searching in all loaded packages or all installed packages
A capacity to set the āactive moduleā of the file youāre modifying so you can use non-exported names
An interface with Lint.jl that automatically highlights syntax errors in your code as you type it
An inbuilt julia debugger based in ASTInterpreter2
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:
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.
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