Isn't this a bit premature? Mojo doesn't tangibly exist for most people (we can't run it ourselves), and I am unaware of any ML/ AI applications built with Mojo.
If they successfully import Pythons libraries without a bunch of wrapping, its userbase will likely follow.
It was faster than Python and easy to do paralleization like go. But it’s not quite fully baked yet.
You know that the entire blogpost you're ostensibly commenting under is about how the JIT overhead has been greatly reduced via more static AOT compilation, right?
Python is not compiled and start & load pandas (which is comparable to the libraries loaded in the article) in ~0.4" on my computer, and that's a notoriously slow language.
If I were to use e.g. Rust with polars, load time would be virtually none. And when I have to process ~50k different datasets, I can't afford 0.85" per file, which would translate to ~11 hours of overhead.
No it's not, because I will not architecture my whole pipeline & program around Julia inability to start in a second, I will just use another language.
Hello C, C++ and Fortran.
Because you're compiling...
And if you need to do the same in Julia, you should also pre-compile or some other method like https://github.com/dmolina/DaemonMode.jl (their demo shows loading a database, with subsequent loads after the first one taking roughly ~0.2% of the first)
But 1.7 seconds at first startup isn't even enough time to articulate a serious thought, much less write any good code.
I struggle to believe it's a dent in anyones workflow.
> I struggle to believe it's a dent in anyones workflow.
This is exactly what I dislike in the Julia community, the ‶if I don't have this issue, then the ones meeting it are holding it wrong″ attitude.
I have no illusions that I'll convince you - I don't think anyones ever done that on the internet :) But for educational purposes and anyone else interested read on. Also to be clear - "performance" is probably not the number one you'll see people advocating strongly for Julia. It's moreso because if you're in a position where you're writing code that is being run on 50K databases, and not editing CSS styles - what you're doing fundamentally, at some point under the hood, is mathematics. And the flow and design of the code should reflect that. Julia gets us a lot closer.
A few things before I mention your use case specifically:
Running
$ julia myprog file_$x.db
But it would would be the equivalent of the bash script in rust (and actually quite similar, as at the end of the day they both target LLVM)
$ cargo build --release
$ ./target/myprog file_$x.db
But obviously you wouldn't compile each time - you'd compile once and distribute the binary, or pre-install the compiled libraries beforehand, whatever. In rust you can obivously easily statically build things and distribute. In python you're just calling pre-built libraries in other languages anyways.
In Julia that's not so easy because we have to carry around the GC, compiler, and even a patched LLVM. (See Why is my "Hello World" executable 300MB?!" posts on PackageCompiler.jl....). But Python obviously has the same issue. Your first solution here is to just precompile all of your libraries and code
With a naive approach:
$ time julia -q noncompiled_prog.jl
1.57s user 0.14s system 177% cpu 0.961 total
$ time julia --sysimage=DataFramesSysImg.so compiled_proj.jl
0.16s user 0.21s system 21% cpu 1.691 total
@parallel for i=1:N
someCoolFunction(args)
end
If Mojo finds it groove and can convince people that static typing is a price to pay for performance I think Julia will have to adopt some sort of a pure AOT compilation mode and forgo the Dynamism that keeps that Just- portion lying around which does seem like an issue for DS/ML folks.
What is wrong with the following to run a script?
$ julia myscript.jl
If you have specific needs that demand, after hitting return, the few seconds of delay for the vast majority of scripts is an issue, you can pre-compile it ahead of time or simply use something like https://github.com/dmolina/DaemonMode.jl
Julia has issues as with all languages but "not being able to quickly run a script" is by far one of the easiest to work around.
> and you can't quickly run a script or REPL for development.
REPL- I disagree. Of course you can - that's how many of use Julia.
> And now Julia has competition from Mojo.
...maybe. The code-samples we've seen from Mojo look very similar to Python, obviously. And that is specifically why a lot of poeple love Julia.
The problems people are more and more interested in (machine learning, etc) are at their base mathematical problems. These languages are all tools to translate mathematics into computer instructions. The code should then ideally look as close to that math as possible. Spamming np.linalg, sp.sparse, and so forth over and over again is just ugly, and the entire Python workflow overly encourages object oriented design for concepts that are mathematically functions. And, well, should be functions. If you're working in these or related fields at all and write any code with Julia, it's hard to not fall in love.
Mojo may make Python faster. But it will still be, roughly, Python.
And considering that the Python 2 -> Python 3 transition has still not completed, I think it's premature to conclude Mojo's python upgrades will get anywhere.
And now Julia has competition from Mojo. Mojo makes some compromises for backward compatibility with the Python world, but it's really solving the problems that hurt AI most. And the folks behind Mojo have a lot of real-world experience migrating a community from one language to another.
I think Julia will remain a niche language, confined to science and statistical computing outside of mainstream data science and machine learning.