It's hard to say anything without comparing the source code. I don't see a github reference, so I don't know if it is available.
I know his pain of rust's type inference gone insane. When things get too strange, I got in the habit of partially constraining the inferred type - you don't have to specify the full type BTW, only the part you want to constrain. Also, I'm playing with intellij which shows the inferred type in the code while you type, very nice.
OTOH, his workflow seems to demonstrate why C doesn't cut it: He spends an important amount of time to debug trough it. He is carefull and still valgrind finds errors. Trying to handle all errors in rust is too much of a burden, which probably means a lot of C errors go unhandled.
These things indicate incomplete understanding of what the C code is actually doing (instead of what it is supposed to do). Now I get the impression he is a more than capable enough developer. And still a simple but not trivial task of < 1kloc contains these kinds of errors. Do you want to trust the stability and security of your networking to this C code?
Don't get me wrong. I'm not hacking on the guy. He could be me, as I have comparable experiences in C and in rust as he describes. But the truth is, I wrote tons of bugs in C and found even more in other people's C code.
Rust takes more thinking things through. It feels slower writing the code. You'll spend a lot of time waiting on the compiler while it does it utter best to hate you and shred your work to pieces. You can't quick and dirty hack trough a job like you do in C. But in the end, the rust result is a lot more trustworthy, and that aspect alone gains you a lot of time lost on troubleshooting all kinds of weird crashes.
It would help if tutorials would advise you not to lean more heavily than you must on type inference. They have a second goal of selling you on the language, and inference is an attractive feature, in simple programs.
You often can't avoid relying on type inference in clever libraries, where the author can't necessarily spell the annotation. It is on the library author to keep that from leaking out to users.
Bugs in Rust and modern C++ are fewer and bigger, because they more often result from misunderstanding the problem or library preconditions than expressing the solution. There are plenty of such bugs, but you have those in C, too, on top of the others.
The problem of modern C++ is all of old C++ comes along for the ride. Even if you write only modern code, and manage to withstand the 'this once only' siren song there are all your (ex-)colleagues writing in their own style.
One of the major plusses of rust is that it gives you basic guarantees. C++ can't do that.
Type inference is super handy in a lot of places. The problem I've run into in the rust book and other intro docs is they almost always use type inference, which makes it harder to learn what is going on. I'd prefer they used explicit types to start and then ease into type inference.
To the point of having something similar to defer in C. Gnu C has attribute cleanup[1][2] which is supported by both GCC and Clang.
Sure its not portable in the strictest sense but these two compilers offer wide enough support that may be sufficient for your use case. systemd uses it, for example.
glib is also a good general purpose library, you do not need to use GObject or it's event loop to make use of it.
The comments on the article page (not here) show that the commenters are not reading the article carefully.
This is a scrupulously written article with deeply meaningful conclusions. Rust is an immature language -- a stage every language goes through! -- and you can tell. What no one knows, yet, is whether its designers have painted themselves into a corner that prevents fixing it. The compiler, too, is immature, and will certainly get better at localizing the causes of problems, but that is a research project.
C++ is legitimately criticized for complexity that comes from its complicated history. It inherited all of C's warts, and more from early experiments that didn't pan out. You can mostly avoid most of them, but promiscuous integer conversion and overflow always lurk, and you never know when you will encounter old-school code that revives the old monsters.
Rust claims benefits from not inheriting legacy hacks (except C linking conventions, which affect function call details), but is rapidly growing its own legacy of past design choices that constrain future choices. The only limits on this problem are foresight and mathematical rigor of design formalisms, and both are limited.
It might be that Rust programmers will need to learn to rely less on type inference, and state types "unnecessarily", just to get understandable error messages. Improvements in the compiler might include its identifying choke points where such a type annotation would help.
Modern C++ coding gives much the same experience of spending extra time satisfying the compiler, then the program mostly works when you do; but the error messages don't take hours to figure out. Usually, the most obscure complaints come out as mismatches between long function-and-template argument lists, where you have to pick out the one word that doesn't match, but these take minutes, not hours, and could be automated without a research project. Much of that will disappear (not all!), with Concepts in C++20.
The difference between the C and C++/Rust experiences is very much like the difference with interpreted languages -- you depend a great deal more on exhaustive testing when the compiler does less.
I know his pain of rust's type inference gone insane. When things get too strange, I got in the habit of partially constraining the inferred type - you don't have to specify the full type BTW, only the part you want to constrain. Also, I'm playing with intellij which shows the inferred type in the code while you type, very nice.
OTOH, his workflow seems to demonstrate why C doesn't cut it: He spends an important amount of time to debug trough it. He is carefull and still valgrind finds errors. Trying to handle all errors in rust is too much of a burden, which probably means a lot of C errors go unhandled.
These things indicate incomplete understanding of what the C code is actually doing (instead of what it is supposed to do). Now I get the impression he is a more than capable enough developer. And still a simple but not trivial task of < 1kloc contains these kinds of errors. Do you want to trust the stability and security of your networking to this C code?
Don't get me wrong. I'm not hacking on the guy. He could be me, as I have comparable experiences in C and in rust as he describes. But the truth is, I wrote tons of bugs in C and found even more in other people's C code.
Rust takes more thinking things through. It feels slower writing the code. You'll spend a lot of time waiting on the compiler while it does it utter best to hate you and shred your work to pieces. You can't quick and dirty hack trough a job like you do in C. But in the end, the rust result is a lot more trustworthy, and that aspect alone gains you a lot of time lost on troubleshooting all kinds of weird crashes.