3 ms·

I hope that's right, but I don't really get it. From a practical standpoint, when you run your tests with msan and asan (and if you have decent test coverage)

by wrsh07 2y ago

I hope that's right, but I don't really get it. From a practical standpoint, when you run your tests with msan and asan (and if you have decent test coverage) I'm not convinced of the benefits of memory safety that eg rust provides Supposing that it is worth it though, why not migrate to rust? I have a friend starting a startup / consultancy to do just that, and it makes more sense than using circle. Even carbon says "if you can use rust, use rust not carbon"

jay-barronville 2y ago
> Supposing that it is worth it though, why not migrate to rust? I have a friend starting a startup / consultancy to do just that, and it makes more sense than using circle. Even carbon says "if you can use rust, use rust not carbon" A key selling point for Circle is the “superset of C++” aspect. What you’re proposing—while feasible for startups—is entirely unreasonable for larger companies, especially those with existing [usually massive] C++ codebases. With enough evangelizing, you might get them to agree to start using something like Rust in new, smaller, and internal projects. However, suggesting a rewrite of anything mission-critical that can directly impact the bottom line to an entirely different language, ecosystem, behaviors, guarantees, community, etc. is one of the most scary proposals you can make to a company. Are the existing engineers proficient in this new language? How long will it take to ramp up? Are there any new costs (not just financial) to adopting this new language (hint: there always are)? Are there legal concerns? How long will the rewrite take (hint: likely longer than the engineers think)? The list goes on. It’s simply too risky a proposition.
- wrsh07 2y ago
  I don't believe your claim about migrating to rust being untenable. Primarily because I worked at Google where I've seen them migrate the codebase consistently through years of development and language updates. If an enormous company like Google can switch CPU architectures, change their numeric types, change out their hash maps, etc, then yes you can migrate to using a whole new language. (If Google thought this was impossible, why bother with carbon?) I say this confidently because I've worked directly with people doing this and seen their work. I will claim one better and say: you can migrate to idiomatic rust (with help from some custom libraries) Should companies do this? Depends on the industry and the needs for the kind of safety rust provides
xmcqdpt2 2y ago
The problem with testing is that you need a very large number of tests to cover a moderately complex piece of software: you need to test most branches obviously, but often you need to test combinations of behaviours such that 100% line testing is still not even close to enough testing. The advantage of compile time verification is that you can prove that certain paths and behaviours are impossible and don't need to be tested. This reduces the space of required tests combinatorially. We all already do that: no one bothers testing (for example) that standard library functions work correctly in their own code base. In Rust (and strongly typed languages in general) there are entire classes of test and assertions that aren't needed anymore.

by wrsh07 2y ago

jay-barronville 2y ago

> Supposing that it is worth it though, why not migrate to rust? I have a friend starting a startup / consultancy to do just that, and it makes more sense than using circle. Even carbon says "if you can use rust, use rust not carbon" A key selling point for Circle is the “superset of C++” aspect. What you’re proposing—while feasible for startups—is entirely unreasonable for larger companies, especially those with existing [usually massive] C++ codebases. With enough evangelizing, you might get them to agree to start using something like Rust in new, smaller, and internal projects. However, suggesting a rewrite of anything mission-critical that can directly impact the bottom line to an entirely different language, ecosystem, behaviors, guarantees, community, etc. is one of the most scary proposals you can make to a company. Are the existing engineers proficient in this new language? How long will it take to ramp up? Are there any new costs (not just financial) to adopting this new language (hint: there always are)? Are there legal concerns? How long will the rewrite take (hint: likely longer than the engineers think)? The list goes on. It’s simply too risky a proposition.

wrsh07 2y ago
I don't believe your claim about migrating to rust being untenable. Primarily because I worked at Google where I've seen them migrate the codebase consistently through years of development and language updates. If an enormous company like Google can switch CPU architectures, change their numeric types, change out their hash maps, etc, then yes you can migrate to using a whole new language. (If Google thought this was impossible, why bother with carbon?) I say this confidently because I've worked directly with people doing this and seen their work. I will claim one better and say: you can migrate to idiomatic rust (with help from some custom libraries) Should companies do this? Depends on the industry and the needs for the kind of safety rust provides

xmcqdpt2 2y ago

The problem with testing is that you need a very large number of tests to cover a moderately complex piece of software: you need to test most branches obviously, but often you need to test combinations of behaviours such that 100% line testing is still not even close to enough testing. The advantage of compile time verification is that you can prove that certain paths and behaviours are impossible and don't need to be tested. This reduces the space of required tests combinatorially. We all already do that: no one bothers testing (for example) that standard library functions work correctly in their own code base. In Rust (and strongly typed languages in general) there are entire classes of test and assertions that aren't needed anymore.