Julia works really well for power users. There are no huge libraries full of C code like pandas or scipy. Instead there are dozens of small, well-tested packages that fill the same role, all hosted on github. That makes fixing issues so much easier.

Granted: outside of numerical/technical computing, the libraries can be lacking (eg. web development) compared to other languages. We're doing it anyway, but it's a more difficult decision.

Could you elaborate? What was the problem and what was the solution?

Memory leak. As explained, it's not really Julia's fault.

This I also found amazing: https://github.com/JuliaLang/julia/issues/28726 . It took 4 hours to go from bug report about bad compiler code generation to a patch.

I have commented with some details there:

https://github.com/JuliaLang/julia/issues/30653#issuecomment...

Isn't Julia's LinearAlgebra a wrapper around BLAS/LAPACK implementations (OpenBLAS/MKL etc.)?

My employer, Invenia, uses Julia for what I would say is at least a medium sized project.

~200k LOC, ~30 people concurrently working on that code base, literally the core product/system that makes us money.

Julia's not perfect, but I would not blanket discount it out of hand for medium projects. Like all technologies the tradeoffs need to be investigated with reference to the task (and team) at hand.

This is not my experience, at least for numeric code. It generates faster code than Golang, because it uses an LLVM backend (and actually supports macros and parametric polymorphism, so doesn't need to do the work at runtime), faster numeric code than Rust via @inbounds and @simd annotations (way more work to disable bounds checks in Rust), and faster than Swift because it doesn't have pervasive reference counting that can sneak in and destroy performance.

However, in response to discussion about Julia having an integrated set of abstractions that provide high performance - you are discussing a collection of features in Rust, Go, Swift, Nim, TensorFlow, Jax, PyTorch, etc. For any single feature, there can always be some other thing that does it better. But it is unclear how that makes one system better than another.

Here are my early experiments at making a pure-julia multi-threaded BLAS using LoopVectorization.jl https://github.com/MasonProtter/Gaius.jl. It absolutely blows a naive triple for loop out of the water and is quite competitive against OpenBLAS until you get to very big sizes.

MArrays will be stack allocated if they don't escape.

One of my in development packages also uses it's own "stack" (MMap a chunk of memory), so that it can have pointers to fast "stack-alocated" arrays.

I played around with LLVM's alloca a bit, but it seems like I could only ever use a single alloca at a time; if I ever used more than one, LLVM would just return the same pointer each time instead of incrementing it. If I have to manage incrementing the pointers myself anyway, I may as well use my own stack, too.

For (the problems I have tested and tuned it on), LoopVectorization produces faster code than C/Fortran, e.g.: https://chriselrod.github.io/LoopVectorization.jl/latest/exa... But it may be more fair to compare it with plutocc. In my early tests (which involved much larger problem sizes), plutocc does a lot better, because (unlike LoopVectorization) it seems to consider memory/caches rather than just registers allocation and instruction costs.

Swift have built in simd same about Rust https://github.com/apple/swift-evolution/blob/master/proposa...

Nim have arraymancer https://github.com/mratsim/Arraymancer

@inbounds it is just compiler option u can use it in any language with LLVM backend i would be suprised if Julia will be faster then Rust/Swift or Nim in this regard. But True about GO in that particular case.

I agree it wouldn't necessarily be faster, but it also wouldn't be slower. Plus in Rust at least disabling bounds checks requires marking code as unsafe, which really gets the community's hackles up.

How many go or swift or Nim issues discuss matmul vs the Julia repo?

Please don't take that as some reasonable representative of general HN culture or sentiment.

what happened to you is exactly what no one here should do.

I wish I could tell the compiler to compile a function only if it can do it without using memory allocations. Often I would rather see a compilation error than the GC making performance of a function unpredictable.

Of course borrow checker would be helpful, but I guess that's too hard to implement, that's why something like this would be a good balance.

I also think Julia would benefit a lot from a list of "we want these but haven't had time for them". People like contributing things they know are desired, and with Julia it's hard to know whether people want or will accept something until you make the PR.

IDE friendly? IDE support is only good because you absolutely need an IDE for this language.

It's an unwieldy, verbose mess of a language.

The bar was low enough for Julia to sound good at the start, but it gives the impression of being "designed" "on-the-fly".