>Overall we feel like the core value propositions that Rust promises (Performance, Reliability, Productivity) have proven true at FullStory. We’re able to write performant code without spending excessive time in optimization.
Sounds like they could have had the same things with a much easier language like Nim. Unless they are using a lot of Rust exclusive features?
>We can confidently make sweeping changes to our codebase, and trust that the Rust compiler will point out anything that isn’t correct.
How true is this?
> Sounds like they could have had the same things with a much easier language like Nim. Unless they are using a lot of Rust exclusive features?
We didn't consider Nim in our language eval (https://bionic.fullstory.com/rust-at-fullstory-part-1/), but you could insert it into the scoring sheet to see how it might fare if we were evaluating it (https://language-compare.glitch.me/). I would be very interested in seeing the result.
I will also caveat that we are building code that ships in other company's apps, so our requirements will be different from others.
> How true is this?
Ballparking some of our internal issue counts here, so please forgive major rounding.
Out of all the crasher bugs on our team (our most serious category obviously), none have been in the Rust code itself. In a handful of cases Rust has caused the platform glue to crash via timing issues (shutting down platform glue in the wrong order/bad assumptions).
Out of all the general bugs (fidelity, wedging, performance, etc), ~90%ish are in our platform glue code -- ObjC/Android -- and the remainder of Rust bugs are again mostly timing/bad assumptions in async code.
It's been really amazing how confident Rust has made us. Code that compiles generally works.
> https://language-compare.glitch.me/
Putting numbers to things like this is a fuzzy business of course, but I'd be interested in comparing notes on some of them:
- I'm surprised Go gets a 1.0 for thread safety, while Java only gets a 0.5. My understanding is that, at the lowest level, producing e.g. a torn pointer is not possible in the Java memory model, while it is possible in Go.
- I think C++ deserves at least a point or two over C for thread safety, for the same reason it gets a couple points for memory safety. The distinction between raw pointers and smart pointers makes it a lot clearer who is supposed to be owning what, and seeing shared_ptr in the code can be a good reminder that something is likely to race.
- Is Rust really harder to learn than C++? :) I'd normally give C++ a lot of points for familiarity, but that's already split into a separate row.
> Putting numbers to things like this is a fuzzy business of course, but I'd be interested in comparing notes on some of them.
Me too. I'm especially surprised that Rust gets a 1.0 for size ("What’s the size impact of this language on the framework we would deliver for our customers?"). For comparison, C also got a 1.0 and Go got a 0.3. I _far_ prefer working in Rust to working in either Go or C, but my experience hasn't been that Rust binaries are anywhere near as small as equivalent C ones.