5 ms·

>Overall we feel like the core value propositions that Rust promises (Performance, Reliability, Productivity) have proven true at FullStory. We’re able to write

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

leetrout 7y ago
As true as it is for the classes of errors compilers check in every other compiled language.
- steveklabnik 7y ago
  Yes and no; there are areas of differentiation between different statically typed languages. For example, Rust has one of the strongest abilities to prevent concurrency/parallelism errors via its type system, but is also missing some other things, like dependent types or higher kinded types.
james-mcelwain 7y ago
Is Nim a viable alternative to Rust? Didn't it just release 1.0? Their production users list[1] doesn't look very impressive. The size of ecosystem matters a lot. [1] https://github.com/nim-lang/Nim/wiki/Companies-using-Nim https://github.com/nim-lang/Nim/wiki/Companies-using-Nim
- sergiotapia 7y ago
  chicken and egg problem. Nim is a viable alternative to Rust, Python programmers feel right at home, compiles to C, and you can use any C library out there. Nim's performance is also ridiculously fast and low memory.
  - aaron-lebo 7y ago
    Not to advocate for one language over another, but sergio, you're right, Nim is ridiculously underrated and a much easier to use than rust. There's just a lot less mental overhead in almost anything and iteration is going to be much faster because lifetimes do get in the way. Unfortunately this is one of those things where hype has kind of won out and I think a lot of people are dismissing an option like Nim simply because we're not talking about it on places like HN. Though, to be fair to Rust, the community is doing a lot of bleeding edge stuff that Nim's community just isn't big enough to.
    - tedmielczarek 7y ago
      I think like so many things we tend to turn programming language discussions into something akin to discussing religion. I really like Rust but that doesn't have to take anything away from other languages. I'll have to take a look at Nim at some point, it sounds like it has a lot of nice qualities! I really love that we're in what feels like an explosion of new and exciting languages to work with. I don't think Rust is the pinnacle of language design, so having more languages explore the space of possibilities is great! With all that being said, when it comes to choosing a language for use in a business context the popularity of the language absolutely does matter. It has an impact on your ability to hire programmers, find packages to solve the problems you have in the language ecosystem, and have tooling that meets your needs, just to name a few. Now there is definitely a chicken-and-egg problem here as someone mentioned in another comment, in that you need adoption to drive adoption. I'd advise you to try not to take these things personally. If you love Nim focus on doing cool things with Nim and making the Nim community a great place to be.
  - danielscrubs 7y ago
    And because it's a chicken and egg problem a company should do...what?
mmastrac 7y ago
> 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/
nfriedly 7y ago
Rust does quite a lot of checks at compile time. It does the obvious ones like type checking (check out the static_assertions library[1]), but it also ensures that there are no race conditions between threads and other memory-safety things like that. [1]: https://docs.rs/static_assertions/1.1.0/static_assertions/ https://docs.rs/static_assertions/1.1.0/static_assertions/
- saghm 7y ago
  I know this gets repeated to the point of being a meme, but I think it's worth being precise about this; Rust guarantees that there are no data races (i.e. accessing memory in one thread while it's being written to in another), but there can still be other types of race conditions (e.g. non-determinism based on which of two threads finishes a given task first).
tedmielczarek 7y ago
> 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? I admit that I don't have more than a passing familiarity with Nim. Rust certainly isn't the only language targeting this niche nowadays, but it has done a lot of things right and we're not the only ones using it. There's no perfect language, they all have positives and negatives. Rust is still new enough that the ease of hiring developers can be a negative, so choosing an even younger language would further exacerbate that problem. Rust also has enough usage these days that we can get a lot of things from crates.io without having to write them ourselves. I don't know how Nim compares but it's pretty hard to get there without having enough adoption. Finally, Rust has had a bit of a trial by fire in terms of making it usable for integrating into existing codebases and shipping production code to users. I was at Mozilla and helped lead part of the Firefox Quantum work to integrate Rust into Firefox. We ran into a number of issues that we surfaced with the Rust team. Those issues generally were fixed in upstream Rust so everyone using Rust benefited from that work. I don't think that's too high of a bar for other languages to clear but it's a lot easier to recommend Rust knowing it has been through that already. > How true is this? I joined FullStory in December and some of my first changes to the codebase were large refactors, well before I understood how everything worked. None of them caused any major regressions that I'm aware of. My experience over 5 years of using Rust is that if you make the compiler happy you are pretty likely to have working code.
- echelon 7y ago
  > I admit that I don't have more than a passing familiarity with Nim. Rust certainly isn't the only language targeting this niche nowadays Don't let the Nim folks fool you. Nim isn't targeting the same space as Rust. It's garbage collected. Nim could see success in challenging Python or Golang, but Rust is rather uniquely positioned to go after bare metal (C, C++), yet have the ergonomics one would expect from Java, Python, Go, etc. Rust is going to eat everything.
  - estebank 7y ago
    Just pattern matching and destructuring being in the language from 1.0 makes Rust a much different beast ergonomics wise than Java, Python and Go. It makes it different than Scala even, as it feels more cohesive to me. There are many things that could be done to make Rust easier at the cost of bare metal semantics, which is why they aren't done, but I am quite happy with the current state of the language and even with those tradeoffs I agree that Rust has great chances of "taking over" a wide range of spaces that are currently dominated by specific technologies.

leetrout 7y ago

As true as it is for the classes of errors compilers check in every other compiled language.

steveklabnik 7y ago
Yes and no; there are areas of differentiation between different statically typed languages. For example, Rust has one of the strongest abilities to prevent concurrency/parallelism errors via its type system, but is also missing some other things, like dependent types or higher kinded types.

james-mcelwain 7y ago

Is Nim a viable alternative to Rust? Didn't it just release 1.0? Their production users list[1] doesn't look very impressive. The size of ecosystem matters a lot. [1] https://github.com/nim-lang/Nim/wiki/Companies-using-Nim https://github.com/nim-lang/Nim/wiki/Companies-using-Nim

sergiotapia 7y ago
chicken and egg problem. Nim is a viable alternative to Rust, Python programmers feel right at home, compiles to C, and you can use any C library out there. Nim's performance is also ridiculously fast and low memory.
- aaron-lebo 7y ago
  Not to advocate for one language over another, but sergio, you're right, Nim is ridiculously underrated and a much easier to use than rust. There's just a lot less mental overhead in almost anything and iteration is going to be much faster because lifetimes do get in the way. Unfortunately this is one of those things where hype has kind of won out and I think a lot of people are dismissing an option like Nim simply because we're not talking about it on places like HN. Though, to be fair to Rust, the community is doing a lot of bleeding edge stuff that Nim's community just isn't big enough to.
  - tedmielczarek 7y ago
    I think like so many things we tend to turn programming language discussions into something akin to discussing religion. I really like Rust but that doesn't have to take anything away from other languages. I'll have to take a look at Nim at some point, it sounds like it has a lot of nice qualities! I really love that we're in what feels like an explosion of new and exciting languages to work with. I don't think Rust is the pinnacle of language design, so having more languages explore the space of possibilities is great! With all that being said, when it comes to choosing a language for use in a business context the popularity of the language absolutely does matter. It has an impact on your ability to hire programmers, find packages to solve the problems you have in the language ecosystem, and have tooling that meets your needs, just to name a few. Now there is definitely a chicken-and-egg problem here as someone mentioned in another comment, in that you need adoption to drive adoption. I'd advise you to try not to take these things personally. If you love Nim focus on doing cool things with Nim and making the Nim community a great place to be.
- danielscrubs 7y ago
  And because it's a chicken and egg problem a company should do...what?

mmastrac 7y ago

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

nfriedly 7y ago

Rust does quite a lot of checks at compile time. It does the obvious ones like type checking (check out the static_assertions library[1]), but it also ensures that there are no race conditions between threads and other memory-safety things like that. [1]: https://docs.rs/static_assertions/1.1.0/static_assertions/ https://docs.rs/static_assertions/1.1.0/static_assertions/

saghm 7y ago
I know this gets repeated to the point of being a meme, but I think it's worth being precise about this; Rust guarantees that there are no data races (i.e. accessing memory in one thread while it's being written to in another), but there can still be other types of race conditions (e.g. non-determinism based on which of two threads finishes a given task first).

tedmielczarek 7y ago

> 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? I admit that I don't have more than a passing familiarity with Nim. Rust certainly isn't the only language targeting this niche nowadays, but it has done a lot of things right and we're not the only ones using it. There's no perfect language, they all have positives and negatives. Rust is still new enough that the ease of hiring developers can be a negative, so choosing an even younger language would further exacerbate that problem. Rust also has enough usage these days that we can get a lot of things from crates.io without having to write them ourselves. I don't know how Nim compares but it's pretty hard to get there without having enough adoption. Finally, Rust has had a bit of a trial by fire in terms of making it usable for integrating into existing codebases and shipping production code to users. I was at Mozilla and helped lead part of the Firefox Quantum work to integrate Rust into Firefox. We ran into a number of issues that we surfaced with the Rust team. Those issues generally were fixed in upstream Rust so everyone using Rust benefited from that work. I don't think that's too high of a bar for other languages to clear but it's a lot easier to recommend Rust knowing it has been through that already. > How true is this? I joined FullStory in December and some of my first changes to the codebase were large refactors, well before I understood how everything worked. None of them caused any major regressions that I'm aware of. My experience over 5 years of using Rust is that if you make the compiler happy you are pretty likely to have working code.

echelon 7y ago
> I admit that I don't have more than a passing familiarity with Nim. Rust certainly isn't the only language targeting this niche nowadays Don't let the Nim folks fool you. Nim isn't targeting the same space as Rust. It's garbage collected. Nim could see success in challenging Python or Golang, but Rust is rather uniquely positioned to go after bare metal (C, C++), yet have the ergonomics one would expect from Java, Python, Go, etc. Rust is going to eat everything.
- estebank 7y ago
  Just pattern matching and destructuring being in the language from 1.0 makes Rust a much different beast ergonomics wise than Java, Python and Go. It makes it different than Scala even, as it feels more cohesive to me. There are many things that could be done to make Rust easier at the cost of bare metal semantics, which is why they aren't done, but I am quite happy with the current state of the language and even with those tradeoffs I agree that Rust has great chances of "taking over" a wide range of spaces that are currently dominated by specific technologies.