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.
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.
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.
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.
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.
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
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.
