Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Is that really due to the language or that we collectively have become better in structuring software projects?


It's at least partly due to the build tooling. `git clone ... && cargo build` (and `cargo test` too) "just works" for 99% of the Rust projects I have interacted with. And it generally works just as well for projects that have been abandoned for 5 years as it does for well maintained projects. The ones it doesn't work with it's usually because they depend on a C or C++ library!

Build tooling for the C/C++ ecosystem is a mess.


You can trust the compiler to yell at you when you break many invariants that would be tacit and implicit in C and even in C++ (even with best practices followed) which can make you much more productive when you’re just familiarizing yourself with a codebase.

Also, the two aren’t necessarily mutually exclusive. Many people learning the language have reported being surprised by the way Rust seems to make "doing things right" the path of least effort, and this applies to best practices in general, not just memory safety.


I’ve had that experience. I had to write code for a complicated reference counted datastructure. The code was a mess at first because I was approaching it the wrong way, but once I understood it well enough to write it correctly all the pieces fell into place. Extraneous complexity was eliminated, and all the possible mistakes turned out to be impossible. The resulting code is so simple and straight forward that anyone can read it and see that it is correct. And as is traditional, the first time it compiled it was correct in all respects.


People have become not just better at structuring projects, but also at writing standard libs and programming languages.

Many features gained a lot of adoption accross languages over the last two decades, like anonymous functions (with convinient arrow syntax), explicit option types instead of implicit null/undefined, match constructs, well-integrated library management, for(each) loops using iterators instead of indices, map/reduce functional iterators, etc. Rust has the advantage of being able to make these core parts of the language and standard library, resulting in an overall more expressive language.

And in rust's view these features should not only be used to make coding more convinient, but also to encode intent and make undesirable things impossible. This is reflected in the standard library (for example it's impossible to access the data protected by a mutex without locking it), and the philosophy is copied by the ecosystem.


I'm suspicious of this as well. It's common for OSS C and C++ projects (at least in embedded) to be mostly undocumented / few comments, have no easy way to debug by printing to console, and have a complicated build process that requires a certain OS and setup.

Top doc comment: The same license info that's in every file. Not helpful for describing what the module does and how it fits in with the rest of the project.


Well, I've refactored large portions of Rust code with ease and I can't imagine doing it with any C/C++ code because I might break some invariant somewhere.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: