Hacker News new | ask | show | jobs
by hojjat12000 1650 days 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?
4 comments

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?
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.)
> 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.

I’ve found Rust interaction with Go via `cgo` to be quite straightforward, fwiw. RPC approaches are also a popular option.
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.
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.
> 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.

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