4 ms·
I think claims of Julia's death are premature. I used it all throughout grad school shortly after it was released, and there are things the language does so mu
by Xcelerate 6y ago
I think claims of Julia's death are premature. I used it all throughout grad school shortly after it was released, and there are things the language does so much better than any other language I know of that I find it hard to imagine it just disappearing into the ether. The only way I can think of it really dying off is if more popular languages absorb the best features of Julia, making it redundant.
It's hard to make inroads into Python's domain because of the strong networks effects, but I think if one or two major companies onboard the language, then we might see a snowball effect.
Personally, I'd like to see a version of Julia with all static typing and Rust-like memory management. That would be pretty close to the perfect language for me.
- coldtea 6y ago>I used it all throughout grad school shortly after it was released, and there are things the language does so much better than any other language I know of that I find it hard to imagine it just disappearing into the ether That is also true of Common Lisp and Smalltalk, though, and both are as good as "into the ether".
- ragnese 6y agoYeah. There's "dead" and there's "DEAD". Many languages are "dead": COBOL, probably Perl 5, Groovy, Common Lisp, etc.
- the_only_law 6y agoGod there's been so many times I've been working on something and fighting with mainstream languages to produce what I want when I find a language that allows me to solve my problem expressively an simply with ease. Some of them see industrial usage but they're still not very common.
- ragnese 6y ago> Personally, I'd like to see a version of Julia with all static typing and Rust-like memory management. That would be pretty close to the perfect language for me. Can you elaborate on two things: 1. What would this language have that Rust doesn't? I don't know Julia. 2. Why?? Rust's memory management is the main reason it isn't being adopted even faster than it is, IMO. The VAST majority of domains don't WANT Rust's memory management. Garbage collection is great and not even "slow" (see OCaml). Rust's memory management has to be the way it is because it needs to be useful in domains where C and C++ are used.
- Xcelerate 6y ago> What would this language have that Rust doesn't? I don't know Julia. Multiple dispatch, homoiconicity (well... more specifically, the ability to generate dependently typed functions at runtime, which is useful for custom matrix routines) > Garbage collection is great and not even "slow" (see OCaml) 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.
- ragnese 6y ago> 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.