Julia is such a great language, it's what really made me care about end enjoy programming. I think it's the modern language which has taken the most lessons from lisps, and has come up with some great ideas of its own too.<p>I think the thing I love most about it and find it so interesting is that it's almost uniquely good at taking a piece of code and transforming it's meaning in various ways, and has so many tools for doing so, available to users not just language devs. There's<p><pre><code> * Multiple dispatch allowing very flexible writing of generic code, and multiple dispatch isn't some tacked on, opt-in extra. Every function in the language is overloadable, and there's no performance penalty for using multiple dispatch
* Parametric typing allows for a huge amount of abstraction over common 'base' types
* Lispy macros let you do metaprogramming that changes the meaning of a piece of syntax
* Generated functions let you intervene at compile time and lets you essentially take over the compilation pipeline and customize the code generation for any given input type signature
* The abstract interpreter interface which lets one essentially take over the compiler and customize your code generation and analysis passes to your heart's content. This is used for instance to support GPUs and automatic differentiation as package offerings.</code></pre>
It was a great idea for a language. In practice though,it's hard to recommend. Great pet project for some mit professors to make a bunch of side money on top of their salaries though. Everyone else riding it is pretty much trying to niche their career rather then build something people can rely on unfortunately. It's the most unstable language I've ever used. In production I watched companies spend millions of dollars, not large companies, dealing with that aspect of it. The ecosystem surrounding it, though it's old enough, is also incredibly weak.<p>It's a shame. So hard to recommend it to anyone outside of an academic environment.
Unfortunately Julia is now a vibe coded project where Claude has moved to the #1 spot for Jun-Aug 2026.<p>Of course their sponsors demand it. So it is in the same place as Ruby: interesting but out of the question.
Julia is fantastic if you do numerical work and want to write out your inner loops explicitly without sacrificing too much performance, either for pedagogical reasons or because you want to fiddle with the algorithm.<p>It is a lot of fun to start from an empty file, add maybe an import LinearAlgebra, and develop things like a convolutional neural network or a Markov-chain Monte Carlo algorithm completely from scratch. And then it is very rewarding to have such a program be fast enough (looking at Python here) to train on the MNIST dataset or find reasonable estimates for critical exponents.<p>I am not sure there are languages better suited than Julia for these kind of things.
Julia also has some of the nicest GPU abstraction frameworks of any language, achieving pretty low friction portability over a decent subset of CUDA, Metal, ROCm and CPU. KernelAbstractions.jl, AcceleratedKernels.jl etc.
And if you don't want to code your own HMM it also has the best (AFAIK) HMM library out there (HiddenMarkovModels.jl).
When I was a grad student at MIT, my desk was across the hall from the Julia people. We even shared a lunch table. Julia is most famous for its optimizing compiler, but many people may not notice the careful work that went into designing the language itself. Matlab this was not! I remember one long conversation where one of them was teaching me about the different types of normalization of unicode. They had to pick one to canonicalize unicode variable names (more useful for a mathy programming language), and they were carefully considering the consequences of the options.
I don’t know if experience has just damaged my brain or what, but I really like matlab’s syntax for what it is. Nice for writing 100 line experiments or using in the REPL. Sort of like the Python of linear algebra, haha. It also has a nice feature where you start getting headaches to let you know you’ve tried to extend it past its comfort zone.<p>Julia seems to sit in this area between Matlab and Fortran where I can’t ever find a reason to learn it instead of just using one of the other two. But people seem to love it (and the GPGPU support sounds like it is good?) so I should probably just make up a reason.
Do you think the criticism in the article "Why I no longer recommend Julia" about correctness is still valid? * there are too many correctness and composability bugs throughout the ecosystem to justify using it in just about any context where correctness matters *<p><a href="https://yuri.is/not-julia/" rel="nofollow">https://yuri.is/not-julia/</a>
Programming languages have bugs. These things happen, and this tired article blows them totally out of proportion.<p>Some languages are less permissive, and have a culture of searching harder for corner cases and dealing with them than others, that is true. I would expect to find less cases like this in Rust, but more cases like this in Python.<p>Julia is an extremely flexible and permissive language, which means that generic code needs to be written carefully and contracts between interfaces need to be thought through.<p>When you combine funky package types like OffsetArrays with functions from a package where the authors didn't think about OffsetArrays, bad things can happen. Those things were then reported and the community has learned a lot about how to deal with those sorts of things.<p>I'm sure an AI agent can crawl through and find a new big list of weird bugs in julia, but that's true even of a language like Rust.
I think that article has been discussed to death and there's not much value in resurrecting it on every single post that mentions Julia. ultimately if you think the language might be a fit for your use case, I'd recommend trying it out and see how you like it first-hand.
As someone who could be tempted by Julia but isn't involved in the community this was a very helpful read, thank you for sharing.
I do. It pairs nicely with this quote from the article:<p>> “With Dyad 3.0, you can upload data and design documents and the system will design an entire aircraft for you,” Shah says
I really want to like Julia. It has a nice type system, a good ecosystem, reasonable syntax, and it’s far faster than Python. But there are several issues with its DX that prevent me from using it: the most severe of which being the complete lack of a cache for the JIT (or JIT like system), inducing multi second compile times for scripts that run in <100ms. There are some external packages that try to solve this issue, but they are far from first-party quality, and, in my experience, are quite buggy.<p>(I last tried Julia a few years ago; perhaps this has been improved since?)
Also the module/import system is still quite painful/hacky. Which is partly due to the long compile times.<p><a href="https://docs.julialang.org/en/v1.13-dev/manual/workflow-tips/" rel="nofollow">https://docs.julialang.org/en/v1.13-dev/manual/workflow-tips...</a>
a between session cache had been merged for 1.14 (release expected within 6-12 months).
I imagine this will only become more important as we have more agents working on codebases in parallel; so a clean solution would be extremely valuable.<p>On the flip side, the rise of agentic coding means that the library/batteries mismatch against python will largely stop mattering. It should be very easy to have an agent implement large libraries -- especially if they can be just a translation from one language to another (esp. one with with better primitives!)
> tried Julia a few years ago; perhaps this has been improved since?<p>The pre-compiled binary outputs are much smaller, and load a lot faster. =3
[dead]
Julia is my go-to when I need a <i>fast</i> language that I can reason about in a functional way. The type system is fine, the pattern matching is pretty darn good, the metaprogramming story could be significantly better but it’s not <i>bad</i> and boy howdy it’s fast. So stinking fast.
Julia is really fun to use, and I think they are onto something with the type system: Complex types interact much better across module boundaries than in most other languages; here's a good talk on this by one of the creators:<p><a href="https://www.youtube.com/watch?v=kc9HwsxE1OY" rel="nofollow">https://www.youtube.com/watch?v=kc9HwsxE1OY</a><p>The biggest drawback of the language in my view is that Julia is an LLVM toolchain "pretending" to be an interpreted language (it is, technically), this often leaks as very slow first execution latency (and almost forces you to keep the interpreter open instead of just calling it on the file you're editing).
Safe for BASIC I believe it's very difficult to make a programming language which is easy-to-learn like the creators of Julia proclaim. It may be somewhat easier to implement specific scientific functionality in the language but does that warrant the creation of yet another language?<p>Scanning the language it doesn't strike me at all as "simple."
Julia abstracts entire programming paradigms in single characters.<p><a href="https://juliahep.github.io/Hands-on-Julia-for-particle-physicists/08-julia-intro-broadcasting.html" rel="nofollow">https://juliahep.github.io/Hands-on-Julia-for-particle-physi...</a><p>BASIC "made simple things easy, and hard things impossible..."<p>Julia is the first language I've seen in years that implicitly abstracts parallelism cleanly. =3
> Julia is the first language I've seen in years that implicitly abstracts parallelism cleanly.<p>What do you mean by “implicitly”? A single dot is short but not implicit.<p>I also do not see <a href="https://docs.julialang.org/en/v1/manual/parallel-computing/" rel="nofollow">https://docs.julialang.org/en/v1/manual/parallel-computing/</a> s mention that such <i>map</i> calls (can) run on multiple threads.
Yes that was the basic trick they learned from Matlab, said to be a billion dollar company built off a single operator: \<p>Which, for anyone who doesn’t know Matlab, is the solve operator; it calls out to a big algorithm that chooses an appropriate solver given the operands, reducing large programs down to a single line.
Thought that it would be about Lisp....
The Julia type system is also great for AI, it makes code generation more robust. I also liked that some Julia code (such as matrix multiplication) can be executed on a GPU with no change and will be almost as fast as possible, although complex algorithms still require writing specialized kernels (which can be done completely in Julia as well).
Yet another example of MIT taking far too much credit for something...
[dead]
[flagged]
Julia uses 1-based indexing. It's competes with R and Matlab for the same set of users. Both R and Julia have their core functions written in C++. Absolutely nothing new.<p>From my experience, grad students use Julia when their PI thinks a new programming language will help differentiate their next NSF proposal among vast funding requests.
This argument over indexing conventions is so tired.<p>I have yet to hear a good argument for why the answer to "How do I get the <i>third</i> element of this array" should be `arr[2]`<p>> Both R and Julia have their core functions written in C++. Absolutely nothing new.<p>What on earth are you talking about? This is at least a <i>novel</i> claim. Some deep parts of julia's compiler are written in C++ but that's about it. Nearly everything in the language is written in julia itself.<p>The only significant foreign codebases in the language are<p><pre><code> * LLVM
* OpenBLAS
* LibUV
</code></pre>
all of which are extremely reasonable foreign things for a language to use (though we are gradually moving more and more of these things to the julia side)
> "How do I get the third element of this array" should be `arr[2]`<p>Ask a carpenter.<p>To get to the third pigeonhole in a racked series of one foot per pigeonhole unit you literally offset two feet from the origin.<p>In C (of course), arr[2] works as well as does 2[arr] as both are literally just syntactic sugar for arr+2<p>ie. The third pigeon hole <i>begins</i> after passing two whole pigeonholes.
> Both R and Julia have their core functions written in C++. Absolutely nothing new.<p>imo this isn't really a good summary. Julia is one of the 3 languages to have done an exascale HPC run <a href="https://arxiv.org/pdf/2309.10292v1" rel="nofollow">https://arxiv.org/pdf/2309.10292v1</a> (Fortran and C are the other 2). Some parts of the compiler are written in c++ (the llvm interface), but doing codegen with llvm is much more similar to C/Rust/Fortran than R/Matlab
It kinda feels like Julia competes for the people who write the libraries for R and Matlab. Writing fast and elegant ODE solvers, etc in Julia seems to be easier than the others and they've attracted a lot of academics for that reason.
I'm currently split between Python and Julia, having used R happily in the past for data analysis and Matlab for this and that in my EE program. For me, Julia crushes one niche that the rest of them are not good at: making the math look like the math.<p><a href="https://docs.sciml.ai/ModelingToolkit/stable/tutorials/nonlinear/" rel="nofollow">https://docs.sciml.ai/ModelingToolkit/stable/tutorials/nonli...</a><p>If you've used something like SciPy or symbolic Matlab or Maxima or whatever, it always feels like I'm very carefully converting the equations I've scribbled down on paper into code and always a little nervous that I've accidentally split one variable into two names or used the wrong equality operator and am going to end up hating life, or accidentally assigned x = sp.Symbol("y") somewhere.<p>The Julia version is just plain beautiful. There's no ceremony other than the three @parameters, @variables, @mtkcompile macros. It lives in its own little world where you don't have to constantly watch your back to make sure you haven't duplicated a symbol somewhere.
Getting linear algebra in a programming language close to math formulas was, for a long time, my reason to use Octave.<p>When I first read about Julia, I was really amazed - especially the type system with its multiple dispatching and not automatically converting between types (e.g., between integers and floats). Though, I do not know, how Julia is today.<p>Today, I use Python instead of Octave (or Julia) - just because it has a large ecosystem and is widely adopted. An additional advantage is that Python has much better OOP features than Octave had back then.<p>However, I wished Julia had the status that Python has today.
I definitely agree. And the common performance optimization metaprogramming (like 'do it this way for this type of input') works so much better with multiple dispatch, tag structs. Way ahead of C++ expression templates and much more pleasant than macros, concepts, etc.<p>Some of the lower-level APIs like those for concurrency were quite poorly thought out though, at least when I last used Julia. Condition variables don't have equivalent of pthread_timed_wait. Condition variables and channels APIs are not well integrated, design wise. I found so many such issues that it convinced me Julia wasn't general purpose enough. It felt like the features were a bit half-baked and had been hacked together by someone who knew their value but lacked the deep experience/knowledge to pull them all together into a single cohesive vision. Same issues as python, POSIX, etc.
Yeah, the nifty part is instead of trying to write your whole multi-threaded high performance tool <i>in</i> Julia, there is excellent support for taking the math work you’ve done and codegen C out of it. Am very happily using that in prod today for a thing and it works awesome.
Julia is fun, but is still mostly an academic language. Very few shops will use it in the private sector. Python is also more common as a prototype integration language, and rarely seen in industrial areas.<p>If you are an EE that wants to remain employed... than make sure you have documented hours with C/C++, Verilog on Zynq, and ladder logic for Rockwell automation products.<p>Best of luck =3
> Julia uses 1-based indexing.<p>That rules it out to become a successor to Python. It sounds reasonable until you start interacting with other libraries.<p>I do know the attemp to justify it for Lua and I don't buy it.
Nearly all languages designed for mathematics are 1-based - R, Matlab, Mathematica, etc. because that's the mathematical convention and allows using formulas directly. The fact that Python isn't is a drawback in the domain.
This is why AI is better at writing code than humans. They just write code and don’t complain about things that don’t matter, like indexing; or another classic, spaces vs tabs. Humans must learn to get past these things.
[dead]