Rendle’s language borrows nothing from Rust, “because Rust is very close to being the perfect language.” (As Rendle sees it, even Rust’s error messages are “like a hug from the compiler.”)
This is the most fundamental philosophy of both the Rust language and the Rust project: we don't think it's sufficient to build robust systems by only including people who don't make mistakes; we think it's better to provide tooling and process to catch and prevent mistakes.
The post in general expresses well the openness of the Rust community to encourage people to participate instead of gatekeeping and insults you see in other communities.
I really like to compare programming languages to types of parents.
Python - Rich parents that like to think that they care about you by throwing money at everything, you have all the possibilities but zero guidance and help when you have a problem. Overall it's okay but you get irritated by the lack of order. It's fun though if you want to go for all the rollercoaster rides around you.
C/C++ - Parents that do not care at all, you can do everything, they don't really care if you are alive or not. You might think that you are responsible and you will never do something bad but everyone fails once in a while(and then you are f*cked). When there's a problem your dad/mom drunkenly mumbles something you barely understand.
JavaScript - Your parents have good intentions but don't know what to do with a child at all, they come up with random rules that "WE FOLLOW" and make up reasons as they go, overall some of it makes sense but you are confused 90% of the time.
Rust - You feel that the parents are smarter than you almost all the time. They set up a bit limiting rules that sometimes annoy you (sometimes you even hate them) but then pretty much always when you actually think why they set up those limitations it is because they care about you and what you do. If you are brave enough you can tell them to close their eyes and only then you can do whatever you want, but you know that this should be used wisely.
Amos also has an updated quote (rolls off the tongue slightly better imo) on the followup blog post:
And you can write logic errors in just about every language! And if you try hard enough I'm sure you can drive a train straight into a tree! It's just much easier with a car.
I'd like to stretch up a bit the concept of "quote" for TWiR and use a portion of a video. I'll include a transcript after it (if I manage to get everything right).
So, nothing is taken from Rust, by the way, because Rust is very close to being the perfect language. And Rust's borrow checker (and lifetime checker and all this other stuff) they make your life very difficult. But the reason they're making life very difficult is because the things you are trying to do are really, really bad and you shouldn't be doing them, and they have the potential to cause your program to crash and do unexpected things.
And Rust knows this and it is not going to let you do these things. But if you haven't tried Rust, just grab it and work through the first couple of chapters of the Rust book and do something wrong, because the error messages in Rust... it's like a hug form the compiler. It's just "There, there. You did your best. Yes, yes. No, you see here where you've done this? No, you can't do that. No, no, i'ts bad. No, what you probably wanted to do was..." It teaches you Rust. The compiler. It's lovely.
The shorter version of a quote I believe would best be:
[...] if you haven't tried Rust, just grab it and work through the first couple of chapters of the Rust book and do something wrong, because the error messages in Rust... it's like a hug form the compiler. It's just "There, there. You did your best. Yes, yes. No, you see here where you've done this? No, you can't do that. No, no, i'ts bad. No, what you probably wanted to do was..." It teaches you Rust. The compiler. It's lovely.
It doesn't matter who points out that "maybe we shouldn't hit ourselves in the head with a rake repeatedly": that feedback ought to be taken under advisement no matter who it comes from.
...I believe this general pattern - [Generic Associated Types] as a way to generically define an operation with types known only to the implementation - is generally useful for a lot of code, as is visible in existing languages with GATs/HKTs. Where Rust really hits the ball out of the park is that it guarantees monomorphisation, allowing these patterns to be truly zero-cost. It's difficult to overstate just how powerful that is.
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.
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.
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.)