4 ms·

I don't want to be dismissive but how much of this success belongs to the team of rock solid senior engineers with enough experience under their belt rather tha

by throwaway642012 4y ago

I don't want to be dismissive but how much of this success belongs to the team of rock solid senior engineers with enough experience under their belt rather than rewrite in Rust?

hawk_ 4y ago
I would let the same team of "rock solid senior engineers" be the judge of that. They seem to think it mattered significantly enough.
- amelius 4y ago
  Or ... since they are now betting fully on Rust, they now want everybody else on Rust too. Because more people == a higher probability that if they run into issues with Rust someone will fix it.
  - farresito 4y ago
    That's a really cynical take on the matter...
robertlagrant 4y ago
The writer seems to give massive credit to the team.
runevault 4y ago
You can give some credit to the fact they were writing it a second time certainly, but as far as we know at least a lot of the people were the same ones who were central to writing V1. So certainly there was some lift from already doing it once, but if they went from a lot of subtle bugs they struggled to track down to having far fewer of them, and those bugs tended to be the types of issue the rust compiler and/or linter normally point out to you, it will certainly make it easier to mitigate the issues. Rust cannot make a bad programmer a good programmer, but the fact it points out several classes of mistakes (sometimes too aggressively, hopefully someday we get Polonia and other improvements to the borrow checker to remove some things that are hard only because of the current implementation of various checking systems) allows far more confidence. I don't care how good someone is, having an automated way to validate large scales of issues aren't there is a big deal, and unlike unit/integration tests you don't have to write these.
- sidlls 4y ago
  It’s likely they could have chosen to stay with Python, C, and C++ and achieved similar results. I’d bet a pretty penny that the fact they were building on lessons learned with the rewrite accounts for almost 100% of the success here.
jokethrowaway 4y ago
A team with no rust experience This mirrors my experience: getting buggy software out is easier and faster in JS (or whatever you're familiar without compile guarantees), getting something out to production is easier with rust. Sometimes you have enough senior developers and discipline to reproduce and catch obscure bugs (which happen more or less based on your software complexity) and you can fix your mess but that's not always feasible.
- KerrAvon 4y ago
  The more senior I get (decades of experience now), the more I appreciate languages that simply remove the mere possibility of entire classes of bugs. Even in Objective-C — a dynamic language with compile-time type enforcement — if something very weird is happening you have to start with “is that object really what I think it is?“
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]

I don't want to be dismissive but how much of this success belongs to the team of rock solid senior engineers with enough experience under their belt rather than rewrite in Rust?

hawk_ 4y ago

I would let the same team of "rock solid senior engineers" be the judge of that. They seem to think it mattered significantly enough.

amelius 4y ago
Or ... since they are now betting fully on Rust, they now want everybody else on Rust too. Because more people == a higher probability that if they run into issues with Rust someone will fix it.
- farresito 4y ago
  That's a really cynical take on the matter...

robertlagrant 4y ago

The writer seems to give massive credit to the team.

runevault 4y ago

You can give some credit to the fact they were writing it a second time certainly, but as far as we know at least a lot of the people were the same ones who were central to writing V1. So certainly there was some lift from already doing it once, but if they went from a lot of subtle bugs they struggled to track down to having far fewer of them, and those bugs tended to be the types of issue the rust compiler and/or linter normally point out to you, it will certainly make it easier to mitigate the issues. Rust cannot make a bad programmer a good programmer, but the fact it points out several classes of mistakes (sometimes too aggressively, hopefully someday we get Polonia and other improvements to the borrow checker to remove some things that are hard only because of the current implementation of various checking systems) allows far more confidence. I don't care how good someone is, having an automated way to validate large scales of issues aren't there is a big deal, and unlike unit/integration tests you don't have to write these.

sidlls 4y ago
It’s likely they could have chosen to stay with Python, C, and C++ and achieved similar results. I’d bet a pretty penny that the fact they were building on lessons learned with the rewrite accounts for almost 100% of the success here.

jokethrowaway 4y ago

A team with no rust experience This mirrors my experience: getting buggy software out is easier and faster in JS (or whatever you're familiar without compile guarantees), getting something out to production is easier with rust. Sometimes you have enough senior developers and discipline to reproduce and catch obscure bugs (which happen more or less based on your software complexity) and you can fix your mess but that's not always feasible.

KerrAvon 4y ago
The more senior I get (decades of experience now), the more I appreciate languages that simply remove the mere possibility of entire classes of bugs. Even in Objective-C — a dynamic language with compile-time type enforcement — if something very weird is happening you have to start with “is that object really what I think it is?“

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]