TWiR quote of the week

Sorry for the spam, I keep finding things I want to post

At Cloudflare we have big Rust projects/teams and onboard new developers regularly.

There is a learning curve. Rust is rigid and unforgiving, and noobs need assistance when the compiler says “no” (although error messages and Clippy do a good job for common mistakes).

However, the big upside is that noobs can contribute safely to Rust projects. Rust limits severity of the damage an inexperienced programmer can cause. Once they manage to get the code to compile, it already has lots of correctness guarantees. “Bad” Rust code may just clone more than strictly necessary, or write 10 lines of code for something that has a helper method in the stdlib, but it won’t corrupt memory or blindly run the happy path without checking for errors. Rust prefers to be locally explicit, so it’s also easy to review.

- kornel on Lobsters


This is where I am. Like for real 100%
Is kornel reading my code?


I have no idea why this comment was deleted. It should be:

The only dynamic language I truly like is Clojure and a large part of that is because the deep immutability constrains state interactions across the system. I found it to be reliable but the pain of major refactors means it’s not something I advocate for on the job. I used to think you had to have that immutability to get the control benefits but Rust’s immutable by default and single writer rule enforced by the compiler achieves most of the practical benefits with much lower runtime overhead.

- u/grayrest on reddit


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.

By Julio Merino in Rust is hard, yes, but does it matter?.


I like the option to have both a foot gun as well as a foot harpoon in the same project.
-- ridicalis @

At least have the footgun and foot harpoon be designed by the same person with a holster that was designed to hold both!
-- thecodedmessage @

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

1 Like

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.

david_chisnall on


Rust takes Python's 'explicit is better than implicit' to the next level, almost to the extreme!


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.

kornel on (again)


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.


In C everybody’s gangsta until someone dereferences a pointer.

-- /u/Schievel1 @


It's okay, Rust doesn't have feelings.

-- Rust-CAS @

Those are getting added in Rust 1.63.

-- 76g2maesu8mk2 @


One more.

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.

-- /u/dpc_pw as part of a response to the previous QOTW @


Quoting @ssokolow on this reddit post: Blog Post: Builder Lite : rust

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


It happened when I least expected it.

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.

Jesus that's a lot of compile errors.

fasterthanlime in The curse of strong typing


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.

--Taywee from the Hacker News network

Credit to @steveklabnik for calling this one out on Twitter.


a wise man once said: give a man tests and he will find bugs for a day, teach a man to fuzz and he will find bugs for the rest of his life

FormalFerris on twitter


true fact: the rust programming language actually evolved independently 5 times in a process known as 'carcinization'

Also from @FormalFerris on Twitter referencing this article on carcinization in actual crustaceans :joy:


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.


Rwlock vs Mutex? Please, tell me like I'm 5

Mutex: "Mom says it's my turn on the synchronization primitive."
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

/u/LyonSyonII and /u/everything-narrative on /r/rust:


That doesn't look like it's from the White House, though.