The “Tooling” category lists Juno and VS Code explicitly, probably because they are considered general-purpose and widely used (and widely usable?). I believe from my very recent experience that Sublime Text 3 is at least on par in terms of capabilities and raw power.
I don’t mean to start any flame wars or fruitless discussions on the merits of various editors, but it seems to me that Julia users need to be made aware of the benefits of using Sublime Text 3 for programming in Julia.
Just a few notes:
The Julia language-syntax mode works flawlessly.
The ability to evaluate selections, lines of code, and files is smooth and matches or exceeds experience I’ve had in other editors.
The terminals in the editor can be made fully functional on Windows, as it is trivial to start cmd, Powershell, git bash, or Linux shell (WSL) within the editor. (I was never able to make this work properly with Atom or with Emacs.)
The power of snippets cannot be exaggerated.
The editor is seriously FAST. (I have had some really bad experiences recently with VS Code which slowed down to a lag of several seconds per action. Atom has always been slowish.)
The ability to program the editor in Python means that integration of the editor with your own Julia code using pycall can go far.
The integration of the editor with Dragon NaturallySpeaking speech recognition means that the power of either can be significantly boosted by synergy with the other. (Pop me a line if you want to find out more.)
Too bad you can’t write the plugins directly in Julia:p
I used Sublime previously, and it’s really good, but started falling behind the rapid development of Atom and VS Code. They seem to have picked up the speed, though. Thanks for reminding me I actually have a paid license.
Main drawback is perhaps that it’s not FOSS, and costs a fair bit for a license (though you get an unlimited trial period.)
Thank you–this is really helpful. I had trouble with the Sublime Text IJulia frontend package which initially caused me to abandon Sublime Text 3 for Julia.
This and the earlier thread on setting up ST3 were wildly helpful! A little copying and editing from your github document and I have all I need for the moment – a solid editor and a Julia REPL running inside it. Possibly the simplest experience I have ever had setting up something like this.
I also added a little bit about having multiple Julia REPLs available with different versions running concurrently. I think I checked that in yesterday.
One note: when I got to the step to make sure there was a Packages\SendCode\support\Julia - Source File.sublime-build file with the indicated contents – it was already there! I believe the SendCode maintainer must have included Julia in the default setup.
@PetrKryslUCSD Thanks to your tutorial, I replicated your Sublime Text setup and customized a bunch of things and now I have a very fast alternative to Juno on my travel laptop.
One tip that maybe you and others already know: to jump from a stacktrace message in the Julia REPL in Terminus to the file and line, one can install the package “Open URL” (Open URL - Packages - Package Control). Then just Alt + double click the file name with line number, and press Enter to perform the action (“subl: open file at line #”). Note if the line wraps within the filename:line# string at the edge of the terminal window, this action would not work correctly as the wrap will mess up the URL this package detects.
Just wish Sublime Text would have similar IDE functionalities as Juno for Julia, that’ll be perfect. Mainly missing are language server related support (there seems to be plugin but never made it work), GUI debugger (including workspace and call stack and watch window), and probably a profiler result display integrated with GUI.
@PetrKryslUCSD do you think it’s within Sublime Text’s capability if only Python plugins are used? And if anybody is actually working on such support?
Well, that is the price to pay for more features!
Sublime is still a click away if I want to view something fast.
Atom is still very good. Comparing to other languages, Matlab programmers suffer from Matlab’s very long load time, and Python users suffer from slow running. You get the idea.
Let’s say MATLAB takes 90 Seconds to load (More like 5-7, something like 2-3 times of Juno, but for the sake of argument). It happens once a day. Really something beyond tolerable. Must be a chapter in the in Human Rights book dealing with this :-).
At least they get a really great IDE once it is loaded. Sometimes you have to suffer for good things.
Matlab’s IDE is awful.