I cannot remember exactly when I discovered Julia or where. But I remember I got intrigued early on and wrote a blogpost about 9 years ago on Tumblr, which is still there comparing Julia to Ruby of all things: https://assoc.tumblr.com/post/70484963303/getting-comfortabl...
The normal thing today is comparing Julia to R, Matlab and Python. But my intro to Julia was actually trying to convert code examples in the O'Reilly book: "Exploring Everyday Things with R and Ruby: Learning About Everyday Things" to Julia.
I thought that worked quite nicely and that the Julia code looked a lot nicer than the Ruby code. It made me write a follow up blog post a few days later: https://assoc.tumblr.com/post/71454527084/cool-things-you-ca...
Unlike your typical Julia user I was always into programming because I wanted to make computer games. I liked playing with Game engine architectures and those exposed me to the problem of handling collision between objects of different types. Multiple-dispatch solves that problem very elegantly. Traditional object-oriented languages are pretty bad at it.
From the perspective of writing clean and expressive code, this really won me over to Julia early on before I had done much serious work with it.
It became my goto language for writing Unix tools, replacing Go, Ruby and Python.
For unix tools, I assume you mean command line tools? In which case how do you ameliorate the long startup time on each invocation?
Hehehe oh yeah, I almost forget about that because I stopped years ago bothering to actually make the tools into separate files that I start from the shell. It is more like Julia is my shell. I'll just have packages with common tools I use and launch them by calling functions from the REPL.
I'll just have packages for doing doing image file conversions in batch, modifying source code, changing configuration files etc.
Actually come to think about it, I used to have shell scripts in a pipeline to build an application for security. We had to obfuscate the source code and stuff like that. When I rewrote to Julia it all ran much faster. Even if there was a startup time, the workload was heavy enough that the higher performance of Julia easily outperformed bash.
Aren't many bash programs written in C? So this is implying Julia is somehow faster than C? Obviously that can't quite be true, but I can definitely imagine that the algorithms implemented in Julia could be fast faster than other algorithms - since the community has such a heavy influence of very hardcore mathematicians that have a string stress towards speed. Probably most of the algorithms in Julia are state of the art and push the boundaries on time complexity.
I was talking about bash scripts. But outperforming C with Julia is perfectly possible. Julia JIT compilation means you can remove overhead of a lot of function calls which C cannot do. A simple example would be sort taking a function pointer doing object comparison.
High level functional style code with things like map and filter can frequently be JIT compiled to optimal machine code.
Fortran is considered faster for numerical code than C and well polished Fortran libraries like BLAS is already getting outperformed by Julia.
For typical systems programming with need to tight control of memory and real time system C will still have the edge. But for anything crunching lots of numbers like data analysis or machine learning Julia will likely outperform everybody else.
Any reference to how Julia outperform Fortran in BLAS? I thought it is/was calling existing BLAS libraries?
Julia currently ships with fortran based Blas, but Octavian.jl is apure Julia matmul that is faster. (it's nowhere near finished though)
Currently there can some nontrivial compilation latency with this approach, but since LV ultimately emits custom LLVM it's actually perfectly compatible with StaticCompiler.jl [2] following Mason's rewrite, so stay tuned on that front.