> Multiple dispatch, homoiconicity (well... more specifically, the ability to generate dependently typed functions at runtime, which is useful for custom matrix

> Multiple dispatch, homoiconicity (well... more specifically, the ability to generate dependently typed functions at runtime, which is useful for custom matrix routines) Ooh. Fair enough. Sounds very cool! > I did HPC work in Julia, and garbage collection was quite a pain. Most of my debugging time was spent figuring out where tiny memory allocations were occurring in for loops. IMO, Julia is as fast or faster than C/C++ provided you don't unintentionally allocate memory in performance critical parts of your code. I ended up eventually just passing preallocated chunks of memory into functions, but then I had to keep track of all that. Okay, fair enough. I was just thinking in terms of what I'm familiar using Python for. For "data stuff" it seems that the community doesn't mind how slow Python is because Pandas and NumPy, etc, all call through to Fortran/C libraries. Since that seems to be "good enough" for the industry at the moment, I was kind of assuming that garbage collection wouldn't be a problem (especially because you can get WAY faster than Python before giving up garbage collection). Also, is it the garbage collection that was a pain, or the allocation that was a pain? Allocation certain takes time. But one of the nice things about garbage collection is that the cost of reclaiming memory can be deferred. People in Rust have even started noticing that being not-garbage-collected doesn't mean "fast"- it's just a different performance profile (https://abramov.io/rust-dropping-things-in-another-thread https://abramov.io/rust-dropping-things-in-another-thread). As an aside, Swift has structs and classes, were classes are automatically reference counted and structs are value types that have scope-based lifetimes, like C++ non-new'd objects.