logoalt Hacker News

tonyarklestoday at 5:16 AM2 repliesview on HN

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.

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.


Replies

skew-aberrationtoday at 6:55 AM

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.

show 1 reply
hasleytoday at 6:39 AM

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.