so I’m trying to figure out a proper workflow for Julia. Apparently, a lot of people use Juypter Notebooks or the Julia REPL directly in the terminal to code. I have no idea how either one of those options is a valid option. It’s like if I’d code python in the python terminal.
I’d like to reproduce my usual coding workflow, that’s: I create a file/project, open it with whatever editor I want (e.g. vim), open a terminal and compile/run the code.
So now I might be mistaken, but it seems that julia doesn’t allow me that but rather forces me into using the julia terminal. So I’m wondering: Isn’t there a CLI tool that I can use? Like a compiler for julia? Maybe it somehow caches the virtual bytecode or whatever julia creates for it’s just-in-time compilation?
Currently my workflow is like that: I create a file, I code, I open a terminal with julia and I include the main file to compile and run it.
While that is a valid use of the julia command, it comes with a lot of drawbacks. From the man page:
If a Julia source file is given as a program (optionally followed by
arguments in args) Julia will execute the program and exit.
the problem here being “and exit”. So if you do let’s say a plot, you never see your plot which leads to you doing something like adding a wait() at the end of your program or whatever. So you have to change your source in order to adjust the behaviour of the CLI. That’s wrong in my opinion.
Another reason one shouldn’t do that, as far as I understood it, is that you just get a huge performance hit. Julia is Just-In-Time compiled and while I’m by far no expert in it I guess that julia does something liek creating virtual bytecode to speed up the compilation. Which probably is the reason for the whole REPL thing to begin with. If you start a REPL session and then run/compile (or whatever one calls it) your code, that virtual bytecode or however it is implemented get’s saved and reused the next time you “recompile” it. If you leave the session, all that work goes out the window. So if you have the workflow:
Code
run julia -e “some stuff” myfile.jl
You basically throw away a lot of work.
At least that’s how I understand it. So it’s not that easy. It’s be nice to just somehow have a CLI tool that doesn’t have those drawbacks.
Ok, so it seems that you are mostly talking about the famous “Time to first plot”, aka TTFP problem.
There is a lot of work going on it, you can read about it here in Discourse.
I have to add that the Julia REPL is far better than the Python one. The normal workflow in Julia is:
Having the REPL open at all times and use Revise.jl such that you don’t have to reinclude files when they change.
The compilation time in Julia is just unnecessary overhead in the workflow you described.
If you really want to, you can compile your file to a binary using PackageCompiler.jl, but for development purposes that is not worth the effort ( since it takes a fair amount of time ).
Well you can use vim to crate a file. Typically with an extension .jl
then to run it julia filename.jl
So keep vim open in one window, :w then run julia in another terminal window
Or you can use VSCode
I like Atom, but we think Atom will be less developed in the future in favour of VScode
Have a look at https://www.julia-vscode.org/
Thanks for all the input. Currently I’m doing what Wikunia described. I’ll see how I like that but that’s the best workflow I came across so far. Was mainly curious to what kind of way to develope there are.
The DeamonMode.jl looks very nice too and I’ll check that out as well.
I would suggest investing a bit of time in understanding these workflows, since they are the natural option for interacting with Julia.
Note that Julia does not compile in the sense that, say, C or C++ does. The ideal development workflow for most people is interacting with a running Julia process by sending code to it (similarly to all languages which have a REPL). If your preferred editor is vim, search the forum for related solutions.
For development, using VSCode with the Julia extension is an excellent choice.
There you have a REPL to run your code (using include, inline evaluation in the editor, run configs, etc.). You do not need to restart the REPL when changing the code of a module / package you are working on thanks to Revise.
Furthermore, you have functionality like git integration, linting, debugging, profiling available.
To be clear, since I don’t think anyone has laid this out explicitly, there are language extensions for vim that enable you to edit files and send lines or the whole file to the repl. In this way, you’re able to operate almost exclusively in your editor of choice, but keep the benefit of longer running Julia sessions so you’re not compiling on every run. The previously mentioned GitHub - dmolina/DaemonMode.jl: Client-Daemon workflow to run faster scripts in Julia might enable you to get pretty close to your current workflow.
More generally, I think the people mentioning other solutions (vs code, pluto etc) are well-meaning, but a bit misguided. While it is perfectly reasonable to expect people to adapt a bit to a Julia workflow (that is we do not have to entertain people who come here saying “if I can’t have exactly the same workflow I use for X, then julia is stupid”), I also think that there are many ways to productively develop in Julia, and we should try to point people towards solutions that are as close as possible to their current workflow.
While I agree that we should direct people to the tools they may find the most familiar/convenient, I don’t think that there is any harm in mentioning other ones. People can just read up a bit about the alternatives and make up their own minds.
In particular, for vim (and Emacs) users the chance of getting distracted by any other tool is quite low.
The (potential) harm is giving the impression of “you’re doing it wrong.” If someone says “I’m trying to do X,” and the responses are all “here’s how to do Y” or “instead, try Z,” while ignoring “X.” I had just a bit of that impression here.
But in general, I agree it’s fine to mention alternatives, as long as they’re clearly mentioned as alternatives, not dismissing what the OP actually wants.
Fair enough - I was putting myself into the mindset of wanting to use VS code and everyone telling me “just use vim” . I suppose y’all are a different breed.
Apparently, a lot of people use Juypter Notebooks or the Julia REPL directly in the terminal to code. I have no idea how either one of those options is a valid option. It’s like if I’d code python in the python terminal.
I think key to this is the use of include.
You aren’t editting code in the REPL (or at least i don’t)
A common workflow is to create a file foo.jl e.g. in vim,
then in the julia REPL, run: include("foo.jl")
which will load and run that file.
Then if you want to change something you edit it in vim (e.g),
and run include("foo.jl") again.
Or to create a package, FooBar
and then with Revise, run using FooBar in the REPL,
and then doing a few commands that you want to test out interactively
and then editting the package if you want to change how they work
and rerunning those commands to see if you now get an answer that you like.
Thanks for all the input. I’m always open for new kind of workflows so I’m not “this is stupid cause I can’t do it like I think I should be able to do it”. I just like vim and terminals. It integrates well with all other aspects of my system and it just feels great. It’s totally fine if my current workflow just doesn’t really fit the situation but that’s the whole point of this thread. To get a see what other people are doing.
I’ll just use vim and a REPL session in a terminal until I get a better understanding of the overall nature of Julia and then adapt my workflow accordingly.
. I suppose y’all are a different breed.