My Experiences with Julia (opens in new tab)

It's interesting how hard this nut is to crack. I have hit all the same types of problems (R is obscene as a programming language, Python too slow and lacks multicore, C is too low level etc etc). I've ended up using Groovy (JVM) for a lot of my scientific work because it is the "least worst" language - dynamic when you want it to be, static when you want it to be, decent if not stellar set of scientific libraries and performant enough (mostly as fast as Java). I have hopes for Nim but it's still not quite there.

But why isn't there something else? Can we really never have our cake and eat it too in this domain?

This article is representative of my experiences as well. I'm thankful to the author for writing it. My favorite parts:

> This slowness affects other software written in Julia as well. For example, my editor formats on save. For most languages, the formatting time-delay is not noticable, but for Julia it sometimes took more than 10 seconds.

> The idea of “You only need to start the interpreter once a day” failed for me.

For me, this is the biggest obstacle to using Julia. It's not designed to support the traditional C/Python/whatever workflow of editing a text file and then interpreting/compiling it; it wants you to be in the REPL all the time. If you don't use the REPL, you have horrible problems with package loading times. So if you're someone who doesn't like developing in a REPL, you're out of luck.

Some comments by Julia users on the post are available here: https://discourse.julialang.org/t/blog-post-about-my-experie...

Personally I feel JITs have gotten too much hype. While they have some advantages in optimization, it seems far outweighed by the downsides. I’d rather have an interpreter for development and a static compiler for production.

these are all very valid pain points with Julia, except I disagree with calling Julia "way more dynamically typed than Python."

I think of Julia as statically duck-typed, which sounds cursed but is incredibly useful IMO. like if you have `foo(x,y,z)=x+ycow(z)`, foo() will work for any x and y with compatible `+` operators, if there's a `cow()` that will accept whatever type `z` is. But it's still static - your code will throw a compile error* if x and y can't be added, or if cow() won't take your z. And unlike Python, Julia can dispatch on types, so you can implement cow() for whatever you want. the type system is, in fact, absurdly powerful. the downside seems to be that it's formally undecidable sometimes, and that you fundamentally can't enforce output types for functions passed as arguments.

the speed is a drag, but it feels like getting a train up to speed - it's slow getting ready to do absurdly heavy lifting.

> Rust is essentially C/C++, but without their ugliness

I'd rephrase that, folks coming primarily from a coding background would probably find this off-putting since Rust's contribution is something quite different from what C/C++ does. It's fairly clear what author means, though.

I still prefer to use Julia, but this is a good summary of the problems that affect me personally as an experienced user (although I do like dynamic typing for most of the work I do).

> The authors of Julia argued that member functions are a bad idea, because it connects a function to a specific datatype

That's actually the thing I love most in Java-like languages. I want to type "foo." and see everything that I can do with foo. If it's not in auto complete -- it doesn't exist.

Compare that with, for example, "len()" in other languages.