>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.
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.
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.
> - 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.
Some of the original reasoning behind the numbers is swapped out, but much of this scoring was that we were burnt so much by the ease of passing objects between threads and accidentally racing that we dinged Java. Our company's experience with Go has just been better, but Go also has first-class goroutines that mostly enforce doing stuff "right", and had better tooling around multithreaded race detection [1] especially at the time.
> - 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.
That's a good point. We might have scored it somewhat differently if we were more familiar with C++ at the time but most of our C++ knowledge on the team was pretty old, and especially sparse around multi-threading.
> - 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.
IIRC, the rationale was that C++ is mostly familiar concepts that senior developers have encountered in some form, while Rust introduces brand new concepts that we just don't have a good reference point for.
This is absolutely fuzzy business, and a different team will have different weights/scores than us!
> 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.
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).
> 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)
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.
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.
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?
> 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.
> 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.
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.
Rust absolutely does not have the ergonomics of any of those languages because it has lifetimes. They are things you don't worry about in those languages.
Have you done a lot of Rust? I spent considerable time in Rust, and at the end of the day, after stepping away from it, I've found multiple options with the kind of ergonomics that make development a lot more productive for me.
Rust is not going to eat everything. I'd bet money on it. Rust will likely un quietly behind the scenes powering lots of great projects, but its audience is limited. I think HN really has a weak spot for understanding how few people even know what it is. I was surprised to ask a CS grad student that's done lots of machine learning about Rust, and he simply didn't know it existed. I like Rust and all that it taught me, but we need to be realistic about its ceiling and what it is appropriate for.
> Rust absolutely does not have the ergonomics of any of those languages because it has lifetimes. They are things you don't worry about in those languages.
You have to worry about them in any non-garbage collected language. There's just no compiler that checks that you're doing it correctly and is the primary source of security bugs for most software.
Understood. To be specific, they said Rust has the ergonomics of Python, Go, and Java, which are garbage collected languages. It does not strike me as realistic.
I don't see how can Rust be more ergonomic than Python, can you elaborate? A data scientist doing some analysis is not concerned with memory safety, why will he waste his time fighting the compiler?
I don't think there's a bright line dividing systems programming problems between GC and non-GC languages. We use Go extensively at FullStory and it works great for a large class of problems. Rust has a compelling story for spaces where GC makes life harder or just isn't feasible. I will say that Rust being usable without GC does seem to put it in a better position around interoperability than languages with a GC, since composing language runtimes and GCs properly is a really challenging problem.
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.
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).
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.
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.
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.
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.
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.
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?