The way I see it the things mentioned are nice appetizers and the data race and borrow checker are the main meal.
IME the most frustrating problems are not that you forgot to exhaust the switch statement or didn't initialise a new field, it's when you get a segfault that's hard to reproduce and you have barely a hint about what's caused it.
If you write the compiler in Rust it could still happen. Rust code (that compiles) has less bugs than the corresponding C but not zero bugs.
It doesn't sound like you went overboard, it sounds like a good project. Maybe you should have written it in Perl 5.001 though.
GCC started having parts written in C++ 12 years ago: https://lwn.net/Articles/542457/
Even with Valgrind it can be tough to distinguish whether your output code is wrong because of a bug in the compiler or because your code was just wrong. There was a change to GCC a few years back that introduced security holes into the FreeBSD and NetBSD kernel because it just threw away code that would only be invoked in "undefined behavior" scenarios. Signed integer overflow I think.
He said if he had used rust - I am saying if he had used C when rust was available 1. The bug would have been fixed. 2. He could have used valgrind. Modern C also has something called ubsan, and another thing called frama-C.
These tools may be inferior to what rust has, but ignoring they exist or comparing 10+ year old C with modern rust is a bad faith argument.
However, I also don't think they particularly help you to distinguish a compiler bug from an error in your understanding of the language semantics, although they sure do help a lot with everyday errors.
With respect to questions of inferiority or superiority, keep in mind that Valgrind and UBSan are only dynamic checkers; they don't help at all with errors that don't occur in your testing. Frama-C is a static checker more similar to Rust's capabilities, but much more limited, but also with cscope-like abilities for reverse-engineering existing source bases.
The great advantage these three tools (and ASan) have is that you don't have to rewrite your C in Rust in order to use them.
I agree and I disagree ;)
I agree because having a type system that directly provides the guarantee that whole classes of runtime error cannot happen provides fast feedback during development at a low cost.
I disagree because even in a press button (+ tuning) approach, you can prove things with Frama-C that the Rust compiler cannot prove (reason why there is runtime bound-checking, implementation defined behavior for integer overflow and so on in Rust). But also because you can prove much more advance properties than "just" absence of runtime errors.
https://frama-c.com/fc-plugins/mthread.html
(And by the way since it is not done by typing it is hard to use on legacy code)
The Rio Receiver came out 21 years ago. That was a Linux box sold as a consumer electronics stereo component; it grabbed MP3s over Ethernet to play them. I don't remember how much it cost but it was less than US$300.
But apparently the original author tried using asan? That seems like an inconsistency in the story.
Guess what, if you install a 10 year old version rust none of your code would not compile at all. Your logic is so flawed its hard to believe you are being serious. If anything it's impressive that a 10 year old C compiler worked most of the time when most other languages are not stable on these timescales.
It's not easy, even in a few hundred lines I had to remove many conveniences to go that far back, but it's very legible. The compiler has my back, I'm never confused about whose fault it is.
Rust is young, but I don't expect this to be any different in 2030.
Rust was not stable in 2012 yet.
I do agree with your overall point though.
Tailrecursive and deeprecursive allow for making any recursive function stack-overflow safe.
Linters are inferior to things the compiler catches for the same reason test cases are inferior: They are not enforced. If the compiler doesn't allow something you can say with confidence you will never see it in the wild. With linters, compiler switches (-Werror) or test cases you'll have no idea.
You can find plenty of reasons to love Rust, without even getting to the technical details.
Not really, once you start something more complicated than hello world and start to try mutate things for example it get 100x more complicated that Python.
I don't know about 100x, using Box and mutexes it is pretty much as complicated or maybe 2x. If you want it to be efficient and leverage all of Rust then sure, but that wasn't what they were meaning.
Look at the first example. It can be very similar.
Strange example, but I suppose making the corresponding python more complex is one way to make them equivalent.
[1] https://www.starlette.io/ [2] https://fastapi.tiangolo.com/ [3] https://trio.readthedocs.io/en/stable/
One tiny program does not a realistic comparison make, of course. There’s tons of situations where either language can make things more complex than this example. But for basic tasks it’s not particularly complicated.
Mutating things is mostly not that difficult, just add mut to the declaration and then &mut if you pass it around.
The most difficult thing was lifetimes.
E: borrows got a little tricky as well
If you program in a functional way anyway, i.e. having data go through a series of filters, it is quite easy. But not all ways of programming are so easy to port to Rust.
In fact, Rust is MORE high level than python and most languages. That is exactly the borrow checker and all the other things are.
What is not, is being "simple" as python.
I code now full Rust and is the most productive language in my +20 years of this. My other picks: python, Delphi, FoxPro.
But is not productive exactly the same way python/delphi is. It has other axes of it. So in some task Python is unmatched and my main pick for scripting or brainstorming stuff. But Rust is the best at being overall productive.
Where is not (today) is lack of time/resources to be there (like GUIs. But honestly, nothing compare to FoxPro/delphi)...
Amen. Every so often I boot up Lazarus and lament what could have been. Even the best web-dev frontend tools and frameworks do not come close.
I wonder if there is even a market for those sorts of tools today, though. I wasn't there for the decline of Delphi (and FoxPro, et al), so I've no real reference as to why they declined.
My dream is rebuild it: https://tablam.org!
The tools are out there, even Delphi is still being sold and having a yearly conference in Germany.
They declined because only developers working at Fortune 500's get to pay for software.
When one only wants to have free beer, they get to have what the street bazaars can offer, instead of what the monks are using at the cathedral.
I would use Rust for Web if I'd have to squeeze every bit of performance. Most of the of the time I don't have such need for performance.
This is very off weird take: Refactoring in Rust is one of their strengths as language (a major one!) where even VERY deep changes can be done in economical times.
Try the same in python is nearly impossible.
And I mean it: I fully rewritten all my app (a fairly complex niche eCommerce platform) to async and remade all things along it.
And I have A LOT of experience building, rewriting, and porting code; and Rust is the faster/more friendly to refactor both large or small in all my years.
However, I concede that get the knowledge with Rust have challenges and my first attempts at this (when doing my hobby https://tablam.org language) were miserable by lack of understanding, so it could be a factor.
A few that come to my mind: C++ Builder, QT, Windows Forms, Xamarin, .NET MAUI.
What about Haskell? Can it be similarly high level as Haskell?
Or that the only users you know about are vocal…because how would you know about the non-vocal ones?
For all the other scenarios of distributed computing or OS IPC, it does very little.
Plus Rust lacks a story how it can work with OpenMP and OpenACC.
It might be worth clarifying that catching data races isn't just about catching race-conditions-which-are-probably-bugs. Data races are full-blown undefined behavior in the C/C++/Rust memory models, which can (not necessarily frequently but under the right conditions) corrupt memory just as badly as a use-after-free or an out-of-bounds write.
Specially if we take into consideration that focusing back into processes is the only solution to prevent certain exploits.