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.
(I last tried Julia a few years ago; perhaps this has been improved since?)
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.
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!)
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.
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.
> Both R and Julia have their core functions written in C++. Absolutely nothing new.
imo this isn't really a good summary. Julia is one of the 3 languages to have done an exascale HPC run https://arxiv.org/pdf/2309.10292v1 (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.
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.
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.
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.
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.
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.
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 in 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.
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.
Oh, my friend, I’m in my 40s now and while I’ve never touched ladder logic (mostly on purpose), I can honestly say I’ve been writing C since the last century and C++ only a few years less. I remember, with pain in my heart, what C++ looked like before C++11, C++14, and C++17. C++03 had just come out when I started and lots of features even there weren’t really all that baked in the toolchains at them time :).
Zynq is super cool and strongly agree that it’s worth looking into, although starting with just a naked little FPGA board might be more approachable. On the other hand, if you’re sufficiently capable with both embedded Linux and Verilog to successfully implement a piece of hardware in the PL and build a driver and userspace for it in the PS, you’re definitely miles ahead of most candidates.
TI/Octavo chips with the PRUs are kind of similar; not that they’re asynchronous logic like the Zynq PL is, but they’re similarly powerful as far as doing hard real-time deterministic jobs driven by an attached Linux core.
Depends what kind of work you do, as product development is different from factory journeyman. I don't see a chaotic market supporting many domestic product development projects for the next 2 years. =3
I'm an electrical engineer and I use Julia for all kinds of analyses that I might have earlier in my career done in a spreadsheet (Lotus 1-2-3 at first!), or later in python (when I had to choose between Numeric or NumArray).
I started using python for various engineering analysis problems around 2001 and I loved it for how fast (due to minimal boilerplate and automatic memory management) I could code up some thought relative to using C or Java. I could tackle problems in ways I just wouldn't have tried otherwise because I couldn't afford the longer time to write it in other languages. However, for problems which needed speed, of course it bogged down.
I started using Julia for ODE stuff in 2018 or 2019 and was thrilled with the speed and conciseness. As others have said, it looks much more like math and a lot of better design choices were made.
Python obviously has a much larger ecosystem and probably always will, and it will remain a safe choice, but you don't set yourself apart by doing the same thing as everyone else.
One thing that I find extremely annoying when I occasionally read Julia code is the pervasive usage of Unicode. I explicitly forbid agents to use any anything other than ASCII for that reason.
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.
This argument over indexing conventions is so tired.
I have yet to hear a good argument for why the answer to "How do I get the third element of this array" should be `arr[2]`
> Both R and Julia have their core functions written in C++. Absolutely nothing new.
What on earth are you talking about? This is at least a novel 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.
The only significant foreign codebases in the language are
* LLVM
* OpenBLAS
* LibUV
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)
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?
Scanning the language it doesn't strike me at all as "simple."
But I agree the shared memory Distributed Computing part of Julia still needs a lot of work. Spawning binary image instances over ssh is too fragile. =3
If you read the tutorial, the broadcast iterators and GPU kernel are often implicit. As the CUDA array type hints means you don't need to explicitly define standard operations unless doing something custom.
I hope one day Julia does a cleaner version of Scala or Erlang/Elixir OTP languages. Clustering on OTP was certainly an area even seasoned gray beards tried to avoid. =3
Yes that was the basic trick they learned from Matlab, said to be a billion dollar company built off a single operator: \
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.
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.
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.
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.
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:
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).
Yeah I think if Julia had a plain interpreted mode or a base template JIT that could tier up to LLVM's, they could drive that execution latency down a lot.
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*
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.
I strongly recommend listening to others experiences and not forwarding some conversion metric for the languages share holders. Maybe there's a lot of wisdom in smart people being vocal enough to say "yea no" about it. It's not like it's one person...
I don't have any financial interest in Julia so I'm a bit confused about the reference to "share holders." I'm just a user.
I'm sure there are lots of smart people who found that the language didn't suit their needs. there are also lots of smart people who love using Julia. both things can be true at the same time.
There are no language share holders, and note that this account was created an hour ago just to post vague nonspecific gripes about Julia.
There are some real issues in the ecosystem. Specifically there is a high proportion of “gradware” because much like other scientific languages there is a high proportion of graduate students doing their projects and then moving on.
The language also encourages relying on packages which can break. But juliaup makes this easy enough to solve by downgrading.
They dictate what their employees are paid to work on, there are no VC investments in The Julia Programming Language
It’s true that MIT and a few other organizations have more influence than others simply because they employ more developers with time/scope to work on the language. Just like every programming language.
But this becomes less true all the time. And most of the direction that is “paid for” is an unadulterated good: JuliaC ahead of time compilation has been requested for over a decade and has made enormous progress.
I have submitted plenty of core contributions, none of which were directed or paid for by VC. the language contributions come from those sufficiently motivated to contribute. if you want to change the direction, you need to do some work.
I'm one of today's lucky 10,000, so I'm glad it was linked here (and would happily read a defence of the language from one of those previous discussions, too).
When the criticisms relate to correctness bugs, I don't think 'try it out and see how you like it' is sufficient. I might love the syntax and the design and so on, but that doesn't tell me whether I'm going to run into serious bugs some time in the future.
I’d like to take a moment to try and explain to the down voters of this post what I think Yuri is saying (please correct me if I’m putting words in your mouth).
The root cause of the issues with Julia is the amount of magic involved in the dynamic dispatch system. It feels really great when two libraries are not written with one another in mind and they just work together as if they were. This has been one of Julia’s biggest selling points and they pushed this idea very hard.
But this magic is also at the root of Julia’s correctness issues. Everyone saying “well these are bugs and all languages have bugs so it’s overblown” is missing the point. The issue is not that there are bugs but that their providence is part of the value proposition of Julia!
Being able to combine all the libraries and data types is great and magic when it works, but it tends to surface hidden interface contracts that are violated in subtle ways, which is the heart of these issues.
And that’s why Yuri says it pairs nicely with the Shah quote, because it’s just another instance of “put your stuff in this box and magic happens”. Okay great but can the magic aircraft it produces verified to actually fly? The Julia answer is “verification would take the magic out of it so you’ll have to verify it yourself”
Programming languages have bugs. These things happen, and this tired article blows them totally out of proportion.
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.
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.
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.
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.
> 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.
My expectation is that when I think I've found a bug in the programming language implementation I'm using, it's actually me that's mistaken (or at least that language lawyers consider me to be mistaken). Hearing about someone who has encountered multiple bugs (in regular use, rather than running a fuzzer or being directly involved in implementing the language) makes me very wary.
Yeah, this is crazy. It's literally a cliché for most programming languages that it's never the compiler's fault. Granted a lot of the Julia bugs seem to be in the standard/core libraries, but still. Even if the bugs are overstated, this cavalier attitude towards correctness in a numerical language is super disconcerting to me.
Corner cases like `prod([Int8(100), Int8(100)]) != prod((Int8(100), Int8(100)))`? Both returned integers, but the left was 10000 while the right was 16. [0]
Which, apparently, sat in the standard library for almost four years after it was introduced before it was fixed. [1]
Even if there was some merit to your argument, I would still find the attitude utterly disqualifying. While it may be technically true that all programming languages have bugs, software and software communities for numerical computing should take responsibility and treat those bugs seriously, not downplay them by pointing to the fact that other software probably has bugs too.
FWIW I don't have a horse in this race. I've used both before, and I currently make money using neither. I liked Julia. I find that article concerning. And I find the attempts by Julia users to discredit that article in this thread, without addressing its substance, even more concerning and disappointing.
Well, bugs can be fixed. But ideally not by a culture that dismisses them as inevitable or unimportant.
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).
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.
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.
Julia might just be the closest thing at the moment to Matlab without being a Matlab clone. I think you're overestimating the learning curve. It has a REPL, with tab completion and ?<funcname> for high-quality help (without resorting to a browser or llm).
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.
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
* 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
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.
It's a shame. So hard to recommend it to anyone outside of an academic environment.
This depends a lot on what you're trying to do with it. There have been companies which did what you described, but there's also companies happily using it.
If you reach into unstable language internals, yes there is a lot of churn. If you use public language interfaces, the language has been extremely stable for a long time.
The ecosystem quality and quantity depends a lot on what you're trying to do. If you're far away from numerics, then yeah, you will struggle a lot more. E.g. I wouldn't want to do web-dev in julia, but if your software product involves needing to solve an ODE, or a lot of linear algebra, I wouldn't want to be anywhere else.
Not griping about the internals. More like breaking changes, weird issues with basic transitive dependencies breaking after a minor version bump to the language. Gave me, and others on the team, the impression that the whole thing was held together with bubblegum and toothpicks.
The ode stuff is cool, but when we reached for it none of the demos ran on recent versions. It was almost like the groups working on it either intentionally made it so you couldn't keep up with them or that again everything was built on a bed of sand.
I agree writing linear algebra in Julia is clean. That said, the cost for adding a few "." Chars or calling a library in any other language far outweighed the costs for trying to buy into the language itself.
I didn't even know you could do web dev in Julia. I don't want to know what that looks like.
That certainly has not been my experience with the language since 1.0
> weird issues with basic transitive dependencies breaking after a minor version bump to the language.
Not sure what exactly this is referring to, but I suspect it was some bugs that happened when some stdlib packages were taken out of the sysimage and started being treated more like regular packages which are pre-installed.
For a couple minor versions, if you instantiated an manifest from a previous version that used some stdlibs, it could error out. That was indeed unfortunate and IMO should not have been released as such, but it's since been fixed.
I will point out though that officially, you are not supposed to use the same manifest across versions.
> didn't even know you could do web dev in Julia. I don't want to know what that looks like.
There's actually some rather cool stuff happening in that space, but yeah it's early days.
Yea this wasn't user error which is the common gaslight trope from the Julia community. Yes some of these instances post dated 1.0 . Yes the average person is sick of being told there's nothing wrong with the technology when there's been a serious track record of it being a disaster. For companies an expensive one.
It's really not early days. The language is about 15 years old. That excuse gets really tired.
It's crazy to me how every person posting positively about Julia has the same tactics. They don't change year after year. They try to draw people in only to find it's a Trainwreck or a waste of time.
I just hope my comments save a start up a few million dollars or a curious hobbyist 5 months of their free time.
Not trying to gaslight you. Especially if you were hitting that issue with the stdlibs, as I said, I don't think we should have allowed a release to go out with that problem. It was treated as bug though and fixed (though it also took longer than hoped).
The manifest thing is a good example of a hard situation. You have a file format that's not designed to be portable across versions, but the usage pattern around it heavily encourages that, so of course it gets used across versions and bad stuff happens. I'm sure theres also some other examples like this one can pull up.
Of course there's cases where we should be doing better. I'm just also saying that this isn't the only experience out there, and the negative experience you're reporting isn't my experience.
> It's really not early days. The language is about 15 years old. That excuse gets really tired.
Please don't twist my words. I was responding to what you said about webdev, and I said there was some interesting things happening in that space, but still early days. I was explicitly referring to the webdev ecosystem being immature, not the language.
> Great pet project for some mit professors to make a bunch of side money on top of their salaries though.
Are people actually making money off of Julia? You don't usually hear about financial incentives in programming languages, especially open source ones....
It's a really nice feature. That said, I do think in the earlier days, the community did get a bit too enthusiastic about it, and used it in a lot of places in the ecosystem that didn't make so much sense.
I think things have come down to a much more reasonable place though now.
There's understandably been a focus on speed, but what I really like about Julia is being able to write clear code: it has a lot of the flexibility and expressiveness that I like in Lisps, but with better numerical libraries than most Lisps/Schemes, and I really like prototyping algorithms in it. To me (an applied mathematician) it is just a nice tool for thinking in. Not having to compromise too much on speed is a big bonus.
nobody "demanded" anything. it's just the most productive way to write code these days. the same is true at the vast majority of software companies (that can afford the $$ on tokens) as well.
No I don’t know how he gets that info. Most contributions to the language these days are AI assisted, but that’s a completely different matter.
IMO if you can afford AI assistance, it would be irresponsible to not use it, given how good AIs are st bug finding and code review
They are green too, which means they were just made today. That's a pretty nice HN feature! It shows that there's literally 5 adversarial green sock puppet accounts that were made just to comment in this thread, so almost certainly one person with a grudge who is afraid to make a non-anonymous argument on the merits.
Is Julia any good for general purpose (non-scientific) use? I guess it probably may not have as many libraries as Python. So what do the library and third party package coverage look like in comparison to languages like Python, Go, etc.?
Lul. No. Everytime one of these "look how amazing Julia pots comes up", myself and many others do what we can to protect other people from wasting their time or their money from using it due to our personal experiences with it professionally or as hobbyists.
Can you give an example of general purpose use? It's not great if you want to make a standalone program and distribute it to other users. It's awesome if you are doing exploratory stuff, quickly exploring different ideas or algorithms. The ecosystem has a lot of high quality stuff but where it lacks you can of course call out to python or R or other languages.
I did some Julia benchmarking over the weekend against a bunch of languages if anyone is interested. The workload is an EKF on an Apple M1, I'm trying to do as many as possible in parallel:
Compared against Taichi, Halide, Futhark, Rust', Lua, LuaJIT, Numpy and pure scalar Python. Julia holds up great it can run basically as fast as you'd like! (These are not apples-to-apples comparisons, picture this as a basket of fruit)
'The Mech results should be understood to be a lower bound on how Rust would perform.
PyPy performs valiantly compared to Cpython -- even better than LuaJIT. I'm sure someone skilled at writing it could do an even better job.
I measured 3 Mojo implementations. The first is a dynamic implementation, it performs like a typical dynamic language. Then when you use Mojo's SIMD intrinsics you can get compiled-tier performance in line with Futhark, Julia, Rust etc.
Then if you use their Max toolchain you can compile Mojo directly to Metal, with performance at the top of the stack (for the amount of money Qualcomm paid they'd better be there!).
The Rust / Mech version was rewritten to put it back on top, but the unchecked test is about equal. Basically if a toolchain can emit direct Metal code there's nothing preventing equal performance it seems, so the magic is in the compiler. Although there is some abstraction overhead depending on how you get there e.g. going wgpu->Metal has a penalty over going directly to Metal.
The big disclaimer again is that all of these measurements should be taken as lower bounds for one algorithm on one machine. I'm sure expert performance engineers could do better.
I'm curious, does anyone use Julia for Operations Research/Optimization/Supply Chain/Logistics? I am trying to learn more about the use of the language in that space. Thx.
115 comments
[ 2.4 ms ] story [ 33.5 ms ] thread(I last tried Julia a few years ago; perhaps this has been improved since?)
The pre-compiled binary outputs are much smaller, and load a lot faster. =3
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!)
https://docs.julialang.org/en/v1.13-dev/manual/workflow-tips...
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.
imo this isn't really a good summary. Julia is one of the 3 languages to have done an exascale HPC run https://arxiv.org/pdf/2309.10292v1 (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
https://docs.sciml.ai/ModelingToolkit/stable/tutorials/nonli...
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.
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.
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.
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.
However, I wished Julia had the status that Python has today.
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.
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.
Best of luck =3
Zynq is super cool and strongly agree that it’s worth looking into, although starting with just a naked little FPGA board might be more approachable. On the other hand, if you’re sufficiently capable with both embedded Linux and Verilog to successfully implement a piece of hardware in the PL and build a driver and userspace for it in the PS, you’re definitely miles ahead of most candidates.
TI/Octavo chips with the PRUs are kind of similar; not that they’re asynchronous logic like the Zynq PL is, but they’re similarly powerful as far as doing hard real-time deterministic jobs driven by an attached Linux core.
https://www.analog.com/en/resources/evaluation-hardware-and-...
> I’ve never touched ladder logic
Depends what kind of work you do, as product development is different from factory journeyman. I don't see a chaotic market supporting many domestic product development projects for the next 2 years. =3
I started using python for various engineering analysis problems around 2001 and I loved it for how fast (due to minimal boilerplate and automatic memory management) I could code up some thought relative to using C or Java. I could tackle problems in ways I just wouldn't have tried otherwise because I couldn't afford the longer time to write it in other languages. However, for problems which needed speed, of course it bogged down.
I started using Julia for ODE stuff in 2018 or 2019 and was thrilled with the speed and conciseness. As others have said, it looks much more like math and a lot of better design choices were made.
Python obviously has a much larger ecosystem and probably always will, and it will remain a safe choice, but you don't set yourself apart by doing the same thing as everyone else.
That rules it out to become a successor to Python. It sounds reasonable until you start interacting with other libraries.
I do know the attemp to justify it for Lua and I don't buy it.
It is better than your code, which is probably a low bar.
why so rude and adversarial, especially when so misinformed? AI code is better than 95% of engineers at this point.
I have yet to hear a good argument for why the answer to "How do I get the third element of this array" should be `arr[2]`
> Both R and Julia have their core functions written in C++. Absolutely nothing new.
What on earth are you talking about? This is at least a novel 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.
The only significant foreign codebases in the language are
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)Ask a carpenter.
To get to the third pigeonhole in a racked series of one foot per pigeonhole unit you literally offset two feet from the origin.
In C (of course), arr[2] works as well as does 2[arr] as both are literally just syntactic sugar for arr+2
ie. The third pigeon hole begins after passing two whole pigeonholes.
Secret mode: ./julia —-lisp
Scanning the language it doesn't strike me at all as "simple."
https://juliahep.github.io/Hands-on-Julia-for-particle-physi...
BASIC "made simple things easy, and hard things impossible..."
Julia is the first language I've seen in years that implicitly abstracts parallelism cleanly. =3
https://cuda.juliagpu.org/stable/tutorials/introduction/
But I agree the shared memory Distributed Computing part of Julia still needs a lot of work. Spawning binary image instances over ssh is too fragile. =3
I hope one day Julia does a cleaner version of Scala or Erlang/Elixir OTP languages. Clustering on OTP was certainly an area even seasoned gray beards tried to avoid. =3
https://youtu.be/lg-710Kk5CM?t=20
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.
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.
I am not sure there are languages better suited than Julia for these kind of things.
https://www.youtube.com/watch?v=kc9HwsxE1OY
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).
There's some exciting work that was presented in Juliacon 2026 though on an upcoming tiered JIT and this should reduce latency a lot, as you suggest.
It's kinda one of those mid-hanging fruits that has been known about for a long time, but not seriously tackled till now.
https://yuri.is/not-julia/
I'm sure there are lots of smart people who found that the language didn't suit their needs. there are also lots of smart people who love using Julia. both things can be true at the same time.
There are some real issues in the ecosystem. Specifically there is a high proportion of “gradware” because much like other scientific languages there is a high proportion of graduate students doing their projects and then moving on.
The language also encourages relying on packages which can break. But juliaup makes this easy enough to solve by downgrading.
It’s true that MIT and a few other organizations have more influence than others simply because they employ more developers with time/scope to work on the language. Just like every programming language.
But this becomes less true all the time. And most of the direction that is “paid for” is an unadulterated good: JuliaC ahead of time compilation has been requested for over a decade and has made enormous progress.
I think you misunderstood my sentiment. That's okay. In a few years you'll probably be where I am now. Setting a reminder for 2 years.
When the criticisms relate to correctness bugs, I don't think 'try it out and see how you like it' is sufficient. I might love the syntax and the design and so on, but that doesn't tell me whether I'm going to run into serious bugs some time in the future.
> “With Dyad 3.0, you can upload data and design documents and the system will design an entire aircraft for you,” Shah says
The root cause of the issues with Julia is the amount of magic involved in the dynamic dispatch system. It feels really great when two libraries are not written with one another in mind and they just work together as if they were. This has been one of Julia’s biggest selling points and they pushed this idea very hard.
But this magic is also at the root of Julia’s correctness issues. Everyone saying “well these are bugs and all languages have bugs so it’s overblown” is missing the point. The issue is not that there are bugs but that their providence is part of the value proposition of Julia!
Being able to combine all the libraries and data types is great and magic when it works, but it tends to surface hidden interface contracts that are violated in subtle ways, which is the heart of these issues.
And that’s why Yuri says it pairs nicely with the Shah quote, because it’s just another instance of “put your stuff in this box and magic happens”. Okay great but can the magic aircraft it produces verified to actually fly? The Julia answer is “verification would take the magic out of it so you’ll have to verify it yourself”
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.
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.
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.
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.
My expectation is that when I think I've found a bug in the programming language implementation I'm using, it's actually me that's mistaken (or at least that language lawyers consider me to be mistaken). Hearing about someone who has encountered multiple bugs (in regular use, rather than running a fuzzer or being directly involved in implementing the language) makes me very wary.
Which, apparently, sat in the standard library for almost four years after it was introduced before it was fixed. [1]
Even if there was some merit to your argument, I would still find the attitude utterly disqualifying. While it may be technically true that all programming languages have bugs, software and software communities for numerical computing should take responsibility and treat those bugs seriously, not downplay them by pointing to the fact that other software probably has bugs too.
FWIW I don't have a horse in this race. I've used both before, and I currently make money using neither. I liked Julia. I find that article concerning. And I find the attempts by Julia users to discredit that article in this thread, without addressing its substance, even more concerning and disappointing.
Well, bugs can be fixed. But ideally not by a culture that dismisses them as inevitable or unimportant.
[0] https://github.com/JuliaLang/julia/issues/39183
[1] https://github.com/JuliaLang/julia/blob/26f2333686ce90331548...
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.
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
* 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
It's a shame. So hard to recommend it to anyone outside of an academic environment.
If you reach into unstable language internals, yes there is a lot of churn. If you use public language interfaces, the language has been extremely stable for a long time.
The ecosystem quality and quantity depends a lot on what you're trying to do. If you're far away from numerics, then yeah, you will struggle a lot more. E.g. I wouldn't want to do web-dev in julia, but if your software product involves needing to solve an ODE, or a lot of linear algebra, I wouldn't want to be anywhere else.
The ode stuff is cool, but when we reached for it none of the demos ran on recent versions. It was almost like the groups working on it either intentionally made it so you couldn't keep up with them or that again everything was built on a bed of sand.
I agree writing linear algebra in Julia is clean. That said, the cost for adding a few "." Chars or calling a library in any other language far outweighed the costs for trying to buy into the language itself.
I didn't even know you could do web dev in Julia. I don't want to know what that looks like.
That certainly has not been my experience with the language since 1.0
> weird issues with basic transitive dependencies breaking after a minor version bump to the language.
Not sure what exactly this is referring to, but I suspect it was some bugs that happened when some stdlib packages were taken out of the sysimage and started being treated more like regular packages which are pre-installed.
For a couple minor versions, if you instantiated an manifest from a previous version that used some stdlibs, it could error out. That was indeed unfortunate and IMO should not have been released as such, but it's since been fixed.
I will point out though that officially, you are not supposed to use the same manifest across versions.
> didn't even know you could do web dev in Julia. I don't want to know what that looks like.
There's actually some rather cool stuff happening in that space, but yeah it's early days.
It's really not early days. The language is about 15 years old. That excuse gets really tired.
It's crazy to me how every person posting positively about Julia has the same tactics. They don't change year after year. They try to draw people in only to find it's a Trainwreck or a waste of time.
I just hope my comments save a start up a few million dollars or a curious hobbyist 5 months of their free time.
The manifest thing is a good example of a hard situation. You have a file format that's not designed to be portable across versions, but the usage pattern around it heavily encourages that, so of course it gets used across versions and bad stuff happens. I'm sure theres also some other examples like this one can pull up.
Of course there's cases where we should be doing better. I'm just also saying that this isn't the only experience out there, and the negative experience you're reporting isn't my experience.
> It's really not early days. The language is about 15 years old. That excuse gets really tired.
Please don't twist my words. I was responding to what you said about webdev, and I said there was some interesting things happening in that space, but still early days. I was explicitly referring to the webdev ecosystem being immature, not the language.
Are people actually making money off of Julia? You don't usually hear about financial incentives in programming languages, especially open source ones....
I think things have come down to a much more reasonable place though now.
Of course their sponsors demand it. So it is in the same place as Ruby: interesting but out of the question.
https://raw.githubusercontent.com/mech-lang/mech/codex/taich...
Compared against Taichi, Halide, Futhark, Rust', Lua, LuaJIT, Numpy and pure scalar Python. Julia holds up great it can run basically as fast as you'd like! (These are not apples-to-apples comparisons, picture this as a basket of fruit)
'The Mech results should be understood to be a lower bound on how Rust would perform.
I added PyPy and Mojo.
PyPy performs valiantly compared to Cpython -- even better than LuaJIT. I'm sure someone skilled at writing it could do an even better job.
I measured 3 Mojo implementations. The first is a dynamic implementation, it performs like a typical dynamic language. Then when you use Mojo's SIMD intrinsics you can get compiled-tier performance in line with Futhark, Julia, Rust etc.
Then if you use their Max toolchain you can compile Mojo directly to Metal, with performance at the top of the stack (for the amount of money Qualcomm paid they'd better be there!).
The Rust / Mech version was rewritten to put it back on top, but the unchecked test is about equal. Basically if a toolchain can emit direct Metal code there's nothing preventing equal performance it seems, so the magic is in the compiler. Although there is some abstraction overhead depending on how you get there e.g. going wgpu->Metal has a penalty over going directly to Metal.
The big disclaimer again is that all of these measurements should be taken as lower bounds for one algorithm on one machine. I'm sure expert performance engineers could do better.