4 ms·
This is very nearly a mechanical line by line conversion of the C to rust. What on earth is so much uglier about it that it renders it "incomprehensible brainfu
by stormbrew 5y ago
This is very nearly a mechanical line by line conversion of the C to rust. What on earth is so much uglier about it that it renders it "incomprehensible brainfuck"?
Is this satire and I'm missing the joke
- db48x 5y agoI assume that they are talking about the abstractions that people sometimes build when working with hardware at a low level. In Rust you can literally build the hardware restrictions into your types, so that for example all registers (or pins in this case) have both read and write methods except the ones that the hardware does not allow you to write to; those only have read methods. Or think about access control: it’s not ok for two programs (or two kernel threads) to interleave accesses to the same GPIO pin, for example. You decide that you want to have some kind of handle or struct that lets you read and write to the pin, but that cannot be duplicated or dropped. This way you can create that object once during initialization, and then pass it to whoever needs it. If you want to call something that needs access to the pin, you then have to pass it the object and you can only regain access to the pin if it passes the object back as a return value. The compiler just won’t let you interleave accesses, because the code won’t even compile if you try to do something not allowed. But all of those neat features add complexity, and often some people just prefer to write comments instead. Usually I recommend starting with very straight–forward code and only adding abstractions in later refactoring steps. Another option is to write the usage code first; this can help you design abstractions without going full architecture astronaut.