4 ms·

> 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 consi

> 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/ 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/ 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.

mwcampbell 7y ago
I'd like to know more about what you found lacking in Kotlin/Native. That would seem to be the lowest-friction option, since Kotlin targets the JVM on Android and Kotlin/Native directly supports interop with Swift.
- mmastrac 7y ago
  Kotlin did pretty well in the matrix [1], though it appeared to be weaker in the areas of memory control and thread safety. These two areas stood out as important because we were bit by them over and over when we had two parallel native codebases written in Java + Objective C. Not crashing our customer applications, and not exposing them to any additional security vulnerabilities is top priority. It's important to keep in mind that we evaluated these options 18 months ago (roughly), so numbers might have changed. Note that we specifically do not use Swift at this time -- even in our platform glue -- because we cannot guarantee that a Swift runtime appears on all devices that we are targeting. We are evaluating options to allow us to use Swift in our glue. [1] https://language-compare.glitch.me/ https://language-compare.glitch.me/
oconnor663 7y ago
> https://language-compare.glitch.me/ 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.
- codesections 7y ago
  > 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.
  - maccam94 7y ago
    Have you tried making them small? Rust doesn't optimize programs for size by default, there's a lot of easy ways to shrink binaries (like stripping symbols). https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust
    - codesections 7y ago
      > Have you tried making them small? Rust doesn't optimize programs for size by default, there's a lot of easy ways to shrink binaries (like stripping symbols). Yeah, I have. I'd come across the guide you linked, any frequently use the subset of those techniques that are available on stable Rust. And I've ended up with simple CLI apps in the 2 to 4 MiB range – which is _fine_ for my use-case, but a bit closer to the size of a Go binary than a C one. (Though, like I said, it's fine for my use case and, if it were important to me, I'm sure I could trim that a bit by picking different dependencies or even dropping to `no_std` in some cases)
saghm 7y ago
I'm a little surprised that Go gets the same score for thread safety as Rust, since safe Rust guarantees a lack of data races, and as far as I know, they can only be caught at runtime in Go. Is there some reason that data races aren't a concern for this project?
saagarjha 7y ago
A couple of those are a bit strange; C++ has less performance than Rust and C? Swift has less memory safety than Rust?

mwcampbell 7y ago

I'd like to know more about what you found lacking in Kotlin/Native. That would seem to be the lowest-friction option, since Kotlin targets the JVM on Android and Kotlin/Native directly supports interop with Swift.

mmastrac 7y ago
Kotlin did pretty well in the matrix [1], though it appeared to be weaker in the areas of memory control and thread safety. These two areas stood out as important because we were bit by them over and over when we had two parallel native codebases written in Java + Objective C. Not crashing our customer applications, and not exposing them to any additional security vulnerabilities is top priority. It's important to keep in mind that we evaluated these options 18 months ago (roughly), so numbers might have changed. Note that we specifically do not use Swift at this time -- even in our platform glue -- because we cannot guarantee that a Swift runtime appears on all devices that we are targeting. We are evaluating options to allow us to use Swift in our glue. [1] https://language-compare.glitch.me/ https://language-compare.glitch.me/

oconnor663 7y ago

> https://language-compare.glitch.me/ 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.

codesections 7y ago
> 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.
- maccam94 7y ago
  Have you tried making them small? Rust doesn't optimize programs for size by default, there's a lot of easy ways to shrink binaries (like stripping symbols). https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust
  - codesections 7y ago
    > Have you tried making them small? Rust doesn't optimize programs for size by default, there's a lot of easy ways to shrink binaries (like stripping symbols). Yeah, I have. I'd come across the guide you linked, any frequently use the subset of those techniques that are available on stable Rust. And I've ended up with simple CLI apps in the 2 to 4 MiB range – which is _fine_ for my use-case, but a bit closer to the size of a Go binary than a C one. (Though, like I said, it's fine for my use case and, if it were important to me, I'm sure I could trim that a bit by picking different dependencies or even dropping to `no_std` in some cases)

saghm 7y ago

I'm a little surprised that Go gets the same score for thread safety as Rust, since safe Rust guarantees a lack of data races, and as far as I know, they can only be caught at runtime in Go. Is there some reason that data races aren't a concern for this project?

saagarjha 7y ago

A couple of those are a bit strange; C++ has less performance than Rust and C? Swift has less memory safety than Rust?