[currymj]

for many types of scientific computing, there's a case to be made it is the best language available. often this type of computing would be in scientific/engineering organizations and not in most software companies. this is its best niche, an important one, but not visible to people with SWE jobs making most software.

it can be used for deep learning but you probably shouldn't, currently, except as a small piece of a large problem where you want Julia for other reasons (e.g. scientific machine learning). They do keep improving this and it will probably be great eventually.

i don't know what the experience is like using it for traditional data science tasks. the plotting libraries are actually pretty nicely designed and no longer have horrible compilation delays.

people who like type systems tend to dislike Julia's type system.

they still have the problem of important packages being maintained by PhD students who graduate and disappear.

as a language it promises a lot and mostly delivers, but those compromises where it can't deliver can be really frustrating. this also produces a social dynamic of disillusioned former true believers.

[csvance]

I work in the medical device industry and most people on my team have engineering degrees and extensive experience with Matlab. Pretty much all of them would flip their table if they had to write numerical/scientific code in Rust, even though it arguably has a more robust type system.

[gugagore]

> people who like type systems tend to dislike Julia's type system.

This is true. As far as I understand it, there is not a type theory basis for Julia's design (type theory seems to have little to say about subtyping type lattices). Relatedly, another comment mentioned that Julia needs sum types.

[pjmlp]

It is the same type theory that has powered Common Lisp and Dylan.