4 ms·

I'm a physicist whose written substantial projects in both Julia and Rust (and C/C++/Object Pascal/Java/Python/...). I'm also a person who refactors frequently.

I'm a physicist whose written substantial projects in both Julia and Rust (and C/C++/Object Pascal/Java/Python/...). I'm also a person who refactors frequently. While my mind was initially blown away by all the cleverness in Julia, I eventually found that for non-trivial packages the "time-to-first-X" became painful - way more painful than compiling Rust code (mostly with debug occasionally with --release). Plus the amazing generality of Julia code was both a blessing and a curse. Julia really needs interfaces to ensure that a duck really is a duck. In the end, I find Rust (despite/maybe because of) the picky compiler to be overall much more productive. With Rust, I find I can make major refactors, when the code compiles and my test code runs, I'm good to go. With Julia, months after I've refactored, I'm still finding footguns. I still use both but it is Rust that has my heart these days. Other thoughts: Developing Rust on Windows is painful but on Linux a joy. both cargo and Julia package managers are wonderful compared to other language alternatives.

miguelraz 2y ago
I'll agree on several counts (as a physicist too!): * Rust's tooling lets you have a base-floor of what is acceptable code that is much more palatable than non-top tier Julia codes. There's a world of difference opening a random crate's code in Rust that has been linted/clippy'd/check'd by the compiler rather than a random Julia package that a coworker/colleague just fired up. This tooling is getting better and better in Julia and I'd be interested to hear which Julia projects you worked on were really hampered by TTFX and refactoring woes. Hard agree on the footguns - I want the VSCode plugin to be better at detecting dead code, it cost me weeks on a project lately. * I'm also excited for some notion of interfaces to come to Julia. Perhaps it will be a 2.0 thing, but there's still lots of design stuff to figure out. * We have different understandings of "productive" for different focii then - I still find it painful to do the equivalent of `rand(1:10, (20, 20))` in Rust and I can get STEM people to be productive with Julia before you can even finishing saying "borrowchecker".
yrlin 2y ago
> ... I eventually found that for non-trivial packages the "time-to-first-X" became painful ... Have you checked the TTFX in 1.9+? It is significantly reduced for various packages e.g. Plots.jl.

miguelraz 2y ago

I'll agree on several counts (as a physicist too!): * Rust's tooling lets you have a base-floor of what is acceptable code that is much more palatable than non-top tier Julia codes. There's a world of difference opening a random crate's code in Rust that has been linted/clippy'd/check'd by the compiler rather than a random Julia package that a coworker/colleague just fired up. This tooling is getting better and better in Julia and I'd be interested to hear which Julia projects you worked on were really hampered by TTFX and refactoring woes. Hard agree on the footguns - I want the VSCode plugin to be better at detecting dead code, it cost me weeks on a project lately. * I'm also excited for some notion of interfaces to come to Julia. Perhaps it will be a 2.0 thing, but there's still lots of design stuff to figure out. * We have different understandings of "productive" for different focii then - I still find it painful to do the equivalent of `rand(1:10, (20, 20))` in Rust and I can get STEM people to be productive with Julia before you can even finishing saying "borrowchecker".

yrlin 2y ago

> ... I eventually found that for non-trivial packages the "time-to-first-X" became painful ... Have you checked the TTFX in 1.9+? It is significantly reduced for various packages e.g. Plots.jl.