4 ms·

> ..complex runtime issues which were almost impossible to reproduce or isolate > That’s when internal murmurs about a complete rewrite started brewing… > We

> ..complex runtime issues which were almost impossible to reproduce or isolate > That’s when internal murmurs about a complete rewrite started brewing… > We decided to move our entire codebase to Rust > there was still one minor problem - no one on the team knew Rust "We have runtime issues so we will fix them by a complete rewrite in a language that no one on the team knows." I would not call that a "hard decision", rather "rolling the dice". It awesome that they managed to make it work.

moonchrome 4y ago
I mean when the tools you know are failing you, you might as well roll the dice.
- draw_down 4y ago
- remram 4y ago
  They could have had some team members learn Rust before deciding that Rust was the right language for the re-write. It feels really risky to do such an important decision only on a high-level view of what you think the language will provide.
bluejekyll 4y ago
I think of rolling the dice as taking a chance without any knowledge of the chance for it paying of. Rust fit the need they had pretty well (on paper anyway since they didn’t have experience with it), and the industry is showing it to be a good choice for solving these types of problems. That’s not rolling the dice, it’s taking a chance based on research.
- meragrin_ 4y ago
  > I think of rolling the dice as taking a chance without any knowledge of the chance for it paying of. I think hoping a Rust rewrite would fix "complex runtime issues which were almost impossible to reproduce or isolate" as rolling the dice. If you cannot reproduce or isolate an issue, how can you know a rewrite in another language will fix the issue?
  - mannykannot 4y ago
    "Almost impossible" is not quite "impossible", and once you have done the almost impossible a few times and isolated the cause of some of the problems, you may have gained some apprehension of the scale of the overall problem you are facing.
- theptip 4y ago
  > I think of rolling the dice as taking a chance without any knowledge of the chance for it paying of. Rolling the dice just means relying on getting lucky (instead of being skillful or controlling the outcome), usually on an unlikely outcome. When you literally roll the dice the odds are completely transparent (1/6 chance of each d6 value). In this case (and in general with big rewrites), the thing you can never know about up-front - and therefore are relying on luck for - is whether you can build the new version within the time/resource budget that you allocate to it. If you get the estimation wrong, or hit unexpected problems/delays, then the rewrite can easily balloon from an ROI-positive project to a massively ROI-negative one. For a startup, this is particularly important because you could run out of runway before your rewrite pays off. This is why most people regard it to be a bad idea (or at least a risky one) to do a full rewrite of a product instead of incrementally evolving it. (Spolsky's essay on the subject I think is the canonical list of concerns with a rewrite: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...)
zaphar 4y ago
If you read it carefully you'll see that they "rewrote" it by replacing components of it. Which: 1. Allowed them to evaluate if it would actually work. 2. Allowed them to train the team on it in a scalable way. The result is that the team learned Rust and Rust fixed a bunch of problems. They were appropriately pragmatic in their approach and Rust was appropriately pragmatic in it's solutions to their problems. If you are ever considering migrating your codebase for some reason this is how you should go about it. TLDR: You are heavily mis-characterizing their team and this article.
P5fRxh5kUvp2th 4y ago
I read it as Rust forced the developers to be specific with their implementations and problems went away as a result. I say this because I'm often _AMAZED_ at just how undisciplined the majority of developers I work with are wrt stability and error propogation.
brabel 4y ago
Yeah, I am really surprised they managed to make it work, actually. Rust is one of those languages it takes time to master... if you write a lot of code in it while you're learning, you're likely to make all sorts of mistakes that later will need to be cleaned up... at least, looking at Rust code I wrote when I was early in the learning process, I can't even imagine any of that code going to production... so I would say it worked for them either because they are highly skilled and can learn difficult things like Rust quickly and efficiently... or their previous code was so completely broken than anything else would be better :D...
- jasim 4y ago
  As a relative newcomer to Rust, I'm curious to hear about those early mistakes
  - stouset 4y ago
    Rust is very good at telling you, the developer, that you've got some flaws in the way you've laid out your program. What it doesn't tell you is that this is frequently a result of having a design that doesn't naturally fit into the kind of more restrictive paradigm that Rust wants you to write programs in. This is a natural consequence of moving from very forgiving languages where almost anything goes (e.g., garbage-collected languages). You'll try to write your software using paradigms that are familiar to you, and many of those don't fit well into the set of restrictions Rust forces upon you. There are escape hatches that let you get around these limitations, and people become very accustomed to using them early on. This happens because the Rust compiler tells you what's wrong and that you can use one of these escape hatches to fix it. But as you continue to build, you have to use more and more of these to overcome the mismatch in your design and the kinds of designs that fit well into Rust's ownership model. I believe it's very important to—early in your Rust career—try and understand if and when the compiler is trying to tell you about a deeper problem with your design than simply throwing surface-level ownership nits at you. I think for some people who are very used to RAII in C++ or very strict C styles, this can come somewhat easily as a lot of the patterns are common (though not enforced at compile-time as in Rust). It is much more difficult for people who are used to garbage-collected languages that tolerate program designs that are entirely unsuitable for languages without a GC.

moonchrome 4y ago

I mean when the tools you know are failing you, you might as well roll the dice.

draw_down 4y ago
remram 4y ago
They could have had some team members learn Rust before deciding that Rust was the right language for the re-write. It feels really risky to do such an important decision only on a high-level view of what you think the language will provide.

bluejekyll 4y ago

I think of rolling the dice as taking a chance without any knowledge of the chance for it paying of. Rust fit the need they had pretty well (on paper anyway since they didn’t have experience with it), and the industry is showing it to be a good choice for solving these types of problems. That’s not rolling the dice, it’s taking a chance based on research.

meragrin_ 4y ago
> I think of rolling the dice as taking a chance without any knowledge of the chance for it paying of. I think hoping a Rust rewrite would fix "complex runtime issues which were almost impossible to reproduce or isolate" as rolling the dice. If you cannot reproduce or isolate an issue, how can you know a rewrite in another language will fix the issue?
- mannykannot 4y ago
  "Almost impossible" is not quite "impossible", and once you have done the almost impossible a few times and isolated the cause of some of the problems, you may have gained some apprehension of the scale of the overall problem you are facing.
theptip 4y ago
> I think of rolling the dice as taking a chance without any knowledge of the chance for it paying of. Rolling the dice just means relying on getting lucky (instead of being skillful or controlling the outcome), usually on an unlikely outcome. When you literally roll the dice the odds are completely transparent (1/6 chance of each d6 value). In this case (and in general with big rewrites), the thing you can never know about up-front - and therefore are relying on luck for - is whether you can build the new version within the time/resource budget that you allocate to it. If you get the estimation wrong, or hit unexpected problems/delays, then the rewrite can easily balloon from an ROI-positive project to a massively ROI-negative one. For a startup, this is particularly important because you could run out of runway before your rewrite pays off. This is why most people regard it to be a bad idea (or at least a risky one) to do a full rewrite of a product instead of incrementally evolving it. (Spolsky's essay on the subject I think is the canonical list of concerns with a rewrite: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...)

zaphar 4y ago

If you read it carefully you'll see that they "rewrote" it by replacing components of it. Which: 1. Allowed them to evaluate if it would actually work. 2. Allowed them to train the team on it in a scalable way. The result is that the team learned Rust and Rust fixed a bunch of problems. They were appropriately pragmatic in their approach and Rust was appropriately pragmatic in it's solutions to their problems. If you are ever considering migrating your codebase for some reason this is how you should go about it. TLDR: You are heavily mis-characterizing their team and this article.

P5fRxh5kUvp2th 4y ago

I read it as Rust forced the developers to be specific with their implementations and problems went away as a result. I say this because I'm often _AMAZED_ at just how undisciplined the majority of developers I work with are wrt stability and error propogation.

brabel 4y ago

Yeah, I am really surprised they managed to make it work, actually. Rust is one of those languages it takes time to master... if you write a lot of code in it while you're learning, you're likely to make all sorts of mistakes that later will need to be cleaned up... at least, looking at Rust code I wrote when I was early in the learning process, I can't even imagine any of that code going to production... so I would say it worked for them either because they are highly skilled and can learn difficult things like Rust quickly and efficiently... or their previous code was so completely broken than anything else would be better :D...

jasim 4y ago
As a relative newcomer to Rust, I'm curious to hear about those early mistakes
- stouset 4y ago
  Rust is very good at telling you, the developer, that you've got some flaws in the way you've laid out your program. What it doesn't tell you is that this is frequently a result of having a design that doesn't naturally fit into the kind of more restrictive paradigm that Rust wants you to write programs in. This is a natural consequence of moving from very forgiving languages where almost anything goes (e.g., garbage-collected languages). You'll try to write your software using paradigms that are familiar to you, and many of those don't fit well into the set of restrictions Rust forces upon you. There are escape hatches that let you get around these limitations, and people become very accustomed to using them early on. This happens because the Rust compiler tells you what's wrong and that you can use one of these escape hatches to fix it. But as you continue to build, you have to use more and more of these to overcome the mismatch in your design and the kinds of designs that fit well into Rust's ownership model. I believe it's very important to—early in your Rust career—try and understand if and when the compiler is trying to tell you about a deeper problem with your design than simply throwing surface-level ownership nits at you. I think for some people who are very used to RAII in C++ or very strict C styles, this can come somewhat easily as a lot of the patterns are common (though not enforced at compile-time as in Rust). It is much more difficult for people who are used to garbage-collected languages that tolerate program designs that are entirely unsuitable for languages without a GC.