I’m finding that the majority of my time goes into writing straightforward business logic and refactoring tests, for which Rust doesn’t get in the way. It’s only during certain parts of the project’s lifetime that I’ve had to build the foundations (abstractions, layering, async constructs, etc.) or done large redesigns, and it’s only during those times that I’ve had my fights with Rust.
In other words: given a sufficiently large project or team, and irrespective of the language, there will always be a set of core maintainers that design, write and maintain the foundations. This set of people knows the ins and outs of the project and should know the ins and outs of the language and its ecosystem. This set of people is necessary . But once these foundations are in place, all other contributors can focus on the exciting aspects of building features. Rust’s complexities may still get in the way, but not much more than those of other languages.
(A conversation on thecodedmessage's latest post on C++ vs. Rust. More specifically, how C++ is more or less three independently designed languages in one, each from a different era of thought, for lack of Rust's focus on tools like Editions.)
It is worth remembering that there is an infinitely large set of programs but a very small set of useful programs. A programming language is a form of ad-hoc compression algorithm, it is intended to sort the set of useful programs to have shorter encodings than the undesirable ones. Programs with certain categories of error or security vulnerability should be harder or impossible to express.
This is the difference in approaches of the two languages. In C++ if the code is vulnerable, the blame is on the programmer. In Rust if the code is vulnerable, Rust considers it a failure of the language, and takes responsibility to stop even “bad” programmers from writing vulnerable code. I can’t stress enough how awesome it is that I can be a careless fool, and still write perfectly robust highly multi-threaded code that never crashes.
I have to raise a little red flag on the above quote least other are led astray with a false sense of security.
When one says software is "vulnerable" that is usually in the context of security. Basically trying to stop bad actors from using systems in bad ways.
Whilst Rust certainly enforces lots of rules to help reduce silly coding errors that introduce memory use and other silly mistakes and whilst that prevents a lot of bugs that could cause security issues it does not ensure ones code does not have security vulnerabilities.
If Rust code contains security vulnerabilities, for example an incorrectly implemented encryption system, the programmar cannot blame the language or compiler for it.
Rust is a perfect language for a dad like me, who every day puts kids to sleep, and tired after long day of work and chores, can sit down and possibly write some code for the hobby open source project, even when he's already just half awake. And it usually just works, tend to be robust and make the day feel extra productive.
Rust's devs came from the functional programming world (To the point that rustc was originally written in Ocaml and people have called Rust "an ML with C++ syntax" and joked about it being "an attempt to trick C++ programmers into writing Haskell") and, generally speaking, when they don't have a feature like Higher-Kinded Types, it's not for lack of trying.
Ironically this quote probably won't make it into next week's TWiR because of ssokolow's own submission above
Someone, somewhere (above me, presumably) made a decision. "From now on", they declared, "all our new stuff must be written in Rust".
I'm not sure where they got that idea from. Maybe they've been reading propaganda. Maybe they fell prey to some confident asshole, and convinced themselves that Rust was the answer to their problems.
I don't know what they see in it, to be honest. It's like I always say: it's not a data race, it's a data marathon.
At any rate, I now find myself in a beautiful house, with a beautiful wife, and a lot of compile errors.
I wrote a bespoke time-series database in Rust a few years ago, and it has had exactly one issue since I stood it up in production, and that was due to pessimistic filesystem access patterns, rather than the language. This thing is handling hundreds of thousands of inserts per second, and it's even threaded.
Given that I've been programming professionally for over a decade in Python, Perl, Ruby, C, C++, Javascript, Java, and Rust, I'll pick Rust absolutely any time that I want something running that I won't get called at 3 AM to fix. It probably took me 5 times as long to write it as if I did it in Go or Python, but I guarantee it's saved me 10 times as much time I would have otherwise spent triaging, debugging, and running disaster recovery.
Because lower-level software has more operational constraints than higher-level software (e.g. it typically cannot tolerate a runtime or memory management via garbage collection), developing a memory safe language suitable for systems software is particularly challenging. The Rust language has met that challenge, however, and is an excellent candidate for replacing C in many systems applications.
We plan to invest in the tools that allow systems engineers to move their software to Rust. This means investing in improving package management, compilers, and Foreign Function Interface (FFI) generators. In many cases this will include providing interfaces compatible with existing widely-used components to enable transition. With these tools, adoption of a memory safe alternative will scale much faster without replication of efforts.
Mutex: "Mom says it's my turn on the synchronization primitive."
vs.
Write lock: "Hey! You all are not allowed to look until I'm done writing!"
Read lock: "Hey! You are not allowed to edit what you wrote until we're done reading it!"
Thanks for an actual 5 year old reply, made me laugh
