The first figure showing color-coded effort is close, but I would say Rust's blue "business logic" portion should be smaller. Pattern matching and linear data types can encode a state machine so much more accurately than C. You're more likely to get the business logic right the first time if you know what patterns to use.
Rust
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
I think this article is spot on. A lot of people I know were turned off from Rust because the compiler was so much stricter than what they were used to, which tends to frustrate experienced devs quickly, in my experience. But it's not that the compiler is overly strict; the errors it catches would almost always become problems later. It's just that reducing the number of compile-time errors doesn't feel like progress as much as reducing the number of run-tine errors, because you haven't actually run the program successfully.
Once you use Rust for a long time, you adapt to the compiler and can get things to compile much quicker. That's where the satisfying part of programming in Rust comes. You get to where you write code and it just works, first try.
You get to where you write code and it just works, first try.
Eh, I write plenty of Rust code that doesn't work. But at least I haven't had a segfault in a while
You get to where you write code and it just works, first try.
Eh, I write plenty of Rust code that doesn't work. But at least I haven't had a segfault in a while
Man, this might even motivate me to stop putting it off and just jump on the train.
I think the author is correct about the compile / test ratio being drastically shifted in rust vs other languages. One thing to have in mind regardng this, is that in larger companies testing may be performed by a dedicated team. Hence, a shift to rust will give the impression of a much higher workload for the developers. In reallity the workload should be pretty much the same since the bugs from testing still needs to be fixed, but that will be spread out over a larger time span due to going by the test team first.
The other thing to consider is that any bug that makes it to the testers or even to production code takes so much more effort to fix than if you had caught the same bug early on. No communication overhead with the testers, no fixing corrupted data in the live database, no scheduled downtimes,...
I’m genuinely interested in reading this blog post but looks like you forgot to link it
Must be some glitch or something, the link is there for me... but here is the link anyway: https://www.linkedin.com/pulse/why-rust-easy-tue-henriksen
Thanks, yeah looks like it was a Memmy app bug. I just opened the post in a browser and the link is there.
Some of this applies to Go too. But it has easier learning curve to begin with.
Go is very different from Rust. I haven't fully learned it but I have tried to find some bugs in some of the Go tools we use and Go code makes it very hard to find the actual business logic in between all the low level stuff that would be abstracted away in Rust.