3 ms·
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 typ
by hyperman1 8y ago
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.
- ncmncm 8y agoIt 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.
- hyperman1 8y agoI still live in Java6 land. I love inference, despite their occasional dark side. Map<String,List<Someclass>> x=new HashMap<String,List<Someclass>>(); 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.
- joshdev 8y agoType 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.