7 ms·

As a long time C programmer this is not very convincing. A C program to do the same requires far less voodoo. All you need to do is take the address of the GP

As a long time C programmer this is not very convincing. A C program to do the same requires far less voodoo. All you need to do is take the address of the GPIO register then toggle the bit. No name mangling. No error handlers to override. Don't get me wrong I know rust does have some compelling features. It does seem odd to me that so many of what would be compiler options in C are hard coded.

steveklabnik 11y ago
We generally try to put options in source code or configuration files, rather than in command-line flags, because that's more repeatable. It makes the CLI much simpler.
izacus 11y ago
Of course that same ability lets you clobber anything else in your address space and leads to those lovely debugging sessions playing "track down what corrupted my datastructure".
- Manishearth 11y ago
  Whilst having to debug this is still undesirable, I recommend trying `rr` (http://rr-project.org/ http://rr-project.org/) to track this if you're ever in such a situation. It's as simple as setting a watchpoint and reverse-continue-ing! I don't do much C/++ these days, but when I do (and it's a large codebase which is hard to debug), `rr` is invaluable. It works with Rust too.
  - pjmlp 11y ago
    Seems quite restrict in terms of platform support.
hatsunearu 11y ago
As the author said at the end, the general "good practice" for Rust is to encapsulate the weird stuff and unsafe blocks into a safe lib that other people can use.
pcwalton 11y ago
Point by point: > All you need to do is take the address of the GPIO register then toggle the bit. Yes, and that is unsafe. Rust makes you put that in an unsafe block, to encourage you to build safe interfaces. This is a good thing. > No name mangling. The alternative to name mangling is not having a module system, with all the fun name conflict issues that come with it. Rust made the right decision here. > No error handlers to override. C has no concept of a panic handler because what would be panics in C are undefined behavior. Undefined behavior is bad for safety and understandability of the code. Having to declare an error handler is a small price to pay. > It does seem odd to me that so many of what would be compiler options in C are hard coded. Because Rust is safe by default. That's one of its most important features. Being more like C in the ways you mention would mean compromising that principle.
- jeffreyrogers 11y ago
  After having played around with Rust a bit and seeing it used in some non-trivial applications I've grown to like it a lot, despite being an initial skeptic. However it's aggravating that in every post about Rust which raises valid criticisms about the language (in this case having to do with the ease with which C allows you to do low level programming), those associated with the Rust project leap to its defense and suggest that Rust's decisions are right for every situation. Just because Rust can't easily do things that C can doesn't make it a bad language, but it does mean that, shockingly, there are somethings that Rust isn't as well positioned for as other languages are. Similarly, there are things that C is bad at. Both at the high level and the low level. At the low level it hides too much of the CPU's features so for some very low level programming you need to drop to assembly. At the high level it has obvious deficiencies, many of which Rust addresses, but for interfacing with the actual hardware it is tough to beat C in terms of convenience.
  - pcwalton 11y ago
    Of those three issues, I see not sectioning off unsafe code as the only real defensible choice when comparing C to Rust. Whether you should have to type "unsafe" is a legitimate tradeoff; if all your code is unsafe, the unsafe keyword adds noise. Undefined behavior and the lack of namespacing don't fall into this category, though. C would be a better language all around if it required that null pointer dereference trap to an error handler (at least on hardware with an MMU or MPU). It would also be a better language if it had a module system. Not every engineering decision is a tradeoff. Sometimes certain decisions are just better all around. I think that modules and error handlers fall into this category.
Animats 11y ago
That's because there's no language syntax for device address space. Modula had DEVICE as a keyword, and you could define structures as being in device space. That's a useful language feature for low-level programming. It tells the compiler that the address space is special - it can change without help from the program. Other features of device space can include that the write width can matter (some registers have to be written as a single byte, world, or double word) and some registers are read-only or write-only. The compiler needs to know this stuff. Especially because Rust makes some strong assumptions about memory. Rust probably needs to know about both device registers and memory shared with peripherals to operate at this level. For the blinky light program it doesn't matter; for the network stack it matters a lot.
0xcde4c3db 11y ago
My experience doing this sort of stuff in C is that this class of complexities is still present, but hidden outside the source in the crt0 and build scripts. Putting it in the actual program text seems like an improvement.
- e12e 11y ago
  Exactly. I saw the gp comment and feared there was lots of boilerplate, arcane incantations -- and the only slightly smelly thing in the (IMNHO) beautiful and short example is the use of an empty asm block to "fight" the compiler on optimizing out the busy loop. I can't imagine the full C example for this is any prettier or easier to follow? [ed: As for "no name mangling" - having such an easy way to turn it off when needed, and yet avoid collisions when you do need it seems pretty good to me. Perhaps just having something that's "extern" be umangled by default would be better -- but it's not like one needs to bend over backwards to get a "mostly safe" bare metal program here.]
  - slackersc 11y ago
    I think you're giving it a bit more credit than necessary. Don't get me wrong, it's cool that they've got it running on a RPi, but it's almost word for word what you'd write in C (right down to needing to inline assembly to get a busy loop to work). The C implementation wouldn't need to bring in a bleeding edge nightly build, worry about name mangling etc..
    - cowsandmilk 11y ago
      The purpose of the article was to show how to get up and running with rust on a Raspberry Pi, not to show how that rust is easier to use than C for programming a Raspberry Pi. Plenty of things I do are are word for word the same in C and python. (import math vs. #include <math.h> , math.sin(x) vs. sin(x), etc.) It is when you want to build something more complex than a blinking light that the differences between languages come out.

steveklabnik 11y ago

We generally try to put options in source code or configuration files, rather than in command-line flags, because that's more repeatable. It makes the CLI much simpler.

izacus 11y ago

Of course that same ability lets you clobber anything else in your address space and leads to those lovely debugging sessions playing "track down what corrupted my datastructure".

Manishearth 11y ago
Whilst having to debug this is still undesirable, I recommend trying `rr` (http://rr-project.org/ http://rr-project.org/) to track this if you're ever in such a situation. It's as simple as setting a watchpoint and reverse-continue-ing! I don't do much C/++ these days, but when I do (and it's a large codebase which is hard to debug), `rr` is invaluable. It works with Rust too.
- pjmlp 11y ago
  Seems quite restrict in terms of platform support.

hatsunearu 11y ago

As the author said at the end, the general "good practice" for Rust is to encapsulate the weird stuff and unsafe blocks into a safe lib that other people can use.

pcwalton 11y ago

Point by point: > All you need to do is take the address of the GPIO register then toggle the bit. Yes, and that is unsafe. Rust makes you put that in an unsafe block, to encourage you to build safe interfaces. This is a good thing. > No name mangling. The alternative to name mangling is not having a module system, with all the fun name conflict issues that come with it. Rust made the right decision here. > No error handlers to override. C has no concept of a panic handler because what would be panics in C are undefined behavior. Undefined behavior is bad for safety and understandability of the code. Having to declare an error handler is a small price to pay. > It does seem odd to me that so many of what would be compiler options in C are hard coded. Because Rust is safe by default. That's one of its most important features. Being more like C in the ways you mention would mean compromising that principle.

jeffreyrogers 11y ago
After having played around with Rust a bit and seeing it used in some non-trivial applications I've grown to like it a lot, despite being an initial skeptic. However it's aggravating that in every post about Rust which raises valid criticisms about the language (in this case having to do with the ease with which C allows you to do low level programming), those associated with the Rust project leap to its defense and suggest that Rust's decisions are right for every situation. Just because Rust can't easily do things that C can doesn't make it a bad language, but it does mean that, shockingly, there are somethings that Rust isn't as well positioned for as other languages are. Similarly, there are things that C is bad at. Both at the high level and the low level. At the low level it hides too much of the CPU's features so for some very low level programming you need to drop to assembly. At the high level it has obvious deficiencies, many of which Rust addresses, but for interfacing with the actual hardware it is tough to beat C in terms of convenience.
- pcwalton 11y ago
  Of those three issues, I see not sectioning off unsafe code as the only real defensible choice when comparing C to Rust. Whether you should have to type "unsafe" is a legitimate tradeoff; if all your code is unsafe, the unsafe keyword adds noise. Undefined behavior and the lack of namespacing don't fall into this category, though. C would be a better language all around if it required that null pointer dereference trap to an error handler (at least on hardware with an MMU or MPU). It would also be a better language if it had a module system. Not every engineering decision is a tradeoff. Sometimes certain decisions are just better all around. I think that modules and error handlers fall into this category.

Animats 11y ago

That's because there's no language syntax for device address space. Modula had DEVICE as a keyword, and you could define structures as being in device space. That's a useful language feature for low-level programming. It tells the compiler that the address space is special - it can change without help from the program. Other features of device space can include that the write width can matter (some registers have to be written as a single byte, world, or double word) and some registers are read-only or write-only. The compiler needs to know this stuff. Especially because Rust makes some strong assumptions about memory. Rust probably needs to know about both device registers and memory shared with peripherals to operate at this level. For the blinky light program it doesn't matter; for the network stack it matters a lot.

0xcde4c3db 11y ago

My experience doing this sort of stuff in C is that this class of complexities is still present, but hidden outside the source in the crt0 and build scripts. Putting it in the actual program text seems like an improvement.

e12e 11y ago
Exactly. I saw the gp comment and feared there was lots of boilerplate, arcane incantations -- and the only slightly smelly thing in the (IMNHO) beautiful and short example is the use of an empty asm block to "fight" the compiler on optimizing out the busy loop. I can't imagine the full C example for this is any prettier or easier to follow? [ed: As for "no name mangling" - having such an easy way to turn it off when needed, and yet avoid collisions when you do need it seems pretty good to me. Perhaps just having something that's "extern" be umangled by default would be better -- but it's not like one needs to bend over backwards to get a "mostly safe" bare metal program here.]
- slackersc 11y ago
  I think you're giving it a bit more credit than necessary. Don't get me wrong, it's cool that they've got it running on a RPi, but it's almost word for word what you'd write in C (right down to needing to inline assembly to get a busy loop to work). The C implementation wouldn't need to bring in a bleeding edge nightly build, worry about name mangling etc..
  - cowsandmilk 11y ago
    The purpose of the article was to show how to get up and running with rust on a Raspberry Pi, not to show how that rust is easier to use than C for programming a Raspberry Pi. Plenty of things I do are are word for word the same in C and python. (import math vs. #include <math.h> , math.sin(x) vs. sin(x), etc.) It is when you want to build something more complex than a blinking light that the differences between languages come out.