5 ms·

Wait, you're complaining that the people who used Rust to write a production software enjoyed it so much that they want that experience for all other softwares

by hojjat12000 5y ago

Wait, you're complaining that the people who used Rust to write a production software enjoyed it so much that they want that experience for all other softwares too? They enjoyed it so much that they told others? and others who also enjoy writing code in this language want to work for you? Are you saying you're afraid that "too much of a good thing" could cause issues for you?

skwirl 5y ago
I feel like I already articulated why I think Rust is not the best choice for most of what we do and you ignored it in order to write a snide response. Can we please keep HN from devolving into Twitter?
- zozbot234 5y ago
  You didn't clarify what your existing stack/tooling is (other than it being based around a GC language), so it's kinda hard to give more detailed feedback. (In general, though, Rust tries its best to make GC-less development as productive as programming in ordinary GC languages, by generalizing the C++ 'RAII' pattern. Wrt. ecosystem concerns, Rust can interoperate with many existing languages though of course some will be harder than others, and interop with GC languages is quite challenging in general.)
  - trevyn 5y ago
    I’ve found Rust interaction with Go via `cgo` to be quite straightforward, fwiw. RPC approaches are also a popular option.
  - kaba0 5y ago
    > Rust tries its best to make GC-less development as productive as programming in ordinary GC languages I think it is generally impossible. While first draft version of the program may have similar velocity, later maintaining will necessarily hit those leaked lower level detail which is simply not a problem with managed languages. But I don’t think that this is a problem in any way or shape.
nine_k 5y ago
It looks like the team greatly enjoys using Rust, but it makes the process of writing the software slower, due to more time spent writing GC-less code, hunting for or writing missing libraries, etc. That is, velocity goes down, even if the probability of bugs and the enjoyment of the team both go up.
- pitaj 5y ago
  I didn't get that impression. Also when calculating velocity we really should include the time it takes to iron out bugs. Rust has a lot of features (sum types, pattern matching, etc) that result in your program being more likely to be correct, not just memory safe.
esjeon 5y ago
> too much of a good thing = blind optimism. When it comes to migration, optimism can be far far worse than pessimism. The hurdle for adoption is much higher for existing projects than new projects.
nprateem 5y ago
Or maybe if it ain't broke don't fix it. Why bother rewriting functioning systems in the language du jour?

skwirl 5y ago

I feel like I already articulated why I think Rust is not the best choice for most of what we do and you ignored it in order to write a snide response. Can we please keep HN from devolving into Twitter?

zozbot234 5y ago
You didn't clarify what your existing stack/tooling is (other than it being based around a GC language), so it's kinda hard to give more detailed feedback. (In general, though, Rust tries its best to make GC-less development as productive as programming in ordinary GC languages, by generalizing the C++ 'RAII' pattern. Wrt. ecosystem concerns, Rust can interoperate with many existing languages though of course some will be harder than others, and interop with GC languages is quite challenging in general.)
- trevyn 5y ago
  I’ve found Rust interaction with Go via `cgo` to be quite straightforward, fwiw. RPC approaches are also a popular option.
- kaba0 5y ago
  > Rust tries its best to make GC-less development as productive as programming in ordinary GC languages I think it is generally impossible. While first draft version of the program may have similar velocity, later maintaining will necessarily hit those leaked lower level detail which is simply not a problem with managed languages. But I don’t think that this is a problem in any way or shape.

nine_k 5y ago

It looks like the team greatly enjoys using Rust, but it makes the process of writing the software slower, due to more time spent writing GC-less code, hunting for or writing missing libraries, etc. That is, velocity goes down, even if the probability of bugs and the enjoyment of the team both go up.

pitaj 5y ago
I didn't get that impression. Also when calculating velocity we really should include the time it takes to iron out bugs. Rust has a lot of features (sum types, pattern matching, etc) that result in your program being more likely to be correct, not just memory safe.

esjeon 5y ago

> too much of a good thing = blind optimism. When it comes to migration, optimism can be far far worse than pessimism. The hurdle for adoption is much higher for existing projects than new projects.

nprateem 5y ago

Or maybe if it ain't broke don't fix it. Why bother rewriting functioning systems in the language du jour?