4 ms·

> Rust and C have an advantage because both are fairly close to the metal, Rust in no_std mode isn't much different than C but the compiler is angry at you all

> Rust and C have an advantage because both are fairly close to the metal, Rust in no_std mode isn't much different than C but the compiler is angry at you all the time. Those things the compiler is angry about? Those are things that would be runtime errors in C. `rustc` is pedantic because it needs to be in order to provide the assurances it gives. There is a subset of "valid" Rust code that `rustc` rejects because it isn't smart enough to understand it would be safe, but I would guess that those cases are less common than than the cases of "seemingly valid" Rust code that is in reality problematic if it were accepted. Beyond that, I would like to hear what errors have made you feel like the compiler "is angry" at you instead of feeling the compiler "is trying to help me". We spend an inordinate amount of effort on 1) accepting code that we should accept by improving ergonomics, 2) provide extensive suggestions when "seemingly correct" code hits the wall of `rustc`'s understanding, language design or things addressable by ergonomics, and 3) provide as good explanations as possible for all other cases. Because of this, I believe the experience of a newcomer today is much better than even a year ago, even though it can still be improved.

zaarn 8y ago
>Those things the compiler is angry about? Those are things that would be runtime errors in C. I'm very very aware of that though this is not always true. For example Rust doesn't have a sane way to have a reentrant mutex without including std, which is bad because for interrupts in a kernel you need to either have very fine grained locking and fallbacks or rely entirely on lockless operations. Interrupts can occur on top of eachother in which case it behave a lot worse than simply being reentrant. rustc yells at me a lot for the solutions this requires because the way I solve it violates ownership rules of rust the hard way to make the code simpler and understandable. Other times it's when for bizarre reason rust wants the code to implement the Sync and Send traits despite the kernel running alone on the core (there is no threading in that kernel) and I would love to be able to tell rustc to just shut up about this and simply ignore Send, possibly even Sync, on a module level.
- richardwhiuk 8y ago
  Linux's kernel runs on more than one core and is pre-emptible, so that's just not generally true.
  - zaarn 8y ago
    In the context of a single core, this happens. Multiple cores make it harder because on top of an interrupt taking locks, other cores now also take locks and you can no longer rely on various promises that a single core gives you. While the Linux kernel can do this, it's not easy to write from scratch, especially because Linux is in C so the compiler doesn't complain about weird things you do.
- steveklabnik 8y ago
  If you know your types are Send and Sync, then you should implement Send and Sync for them. That's how you "tell rustc to just shut up about this."
  - zaarn 8y ago
    They aren't Send and Sync, ie not multithreading safe, they are however, reentrant safe, which is all I need. rustc complaints and I don't want to implement traits on types that don't need them and don't adhere to the contract of the trait.
- pcwalton 8y ago
  You shouldn't have to worry about Send and Sync if you aren't using generic types that require that their type parameters be Send and Sync. What such types are you using?
  - zaarn 8y ago
    Various no_std libs use Send+Sync in places which makes things fun. Another would be static mutable variables, which are perfectly safe in a single-threaded environment, doubly so if you map that memory on a per-core basis to ensure each kernel has a unique variable value. Esp if you need lazy_static then there aren't many options other than wrapping the data in a mutex for no good reason.
mehrdadn 8y ago
> Those things the compiler is angry about? Those are things that would be runtime errors in C. > There is a subset of "valid" Rust code that `rustc` rejects because it isn't smart enough to understand it would be safe Way to tell him he's wrong only to then proceed to directly contradict yourself...
- estebank 8y ago
  > [...] but I would guess that those cases are less common than than the cases of "seemingly valid" Rust code that is in reality problematic if it were accepted. I would guess that most people starting to try out Rust are hitting the latter more often than the former. "Valid" Rust code that `rustc` rejects is uncommon (and for the most part, a bug), but wanted to acknowledge it happens. A "common" case of it would self-referencing structs, but that is considered a bug to be solved. I've only personally experienced problems with valid code being rejected when expressing complex trees involving associated types with their own independent lifetimes[1][2][3]. [1]: https://github.com/rust-lang/rust/issues/55756 https://github.com/rust-lang/rust/issues/55756 [2]: https://github.com/rust-lang/rust/issues/54378 https://github.com/rust-lang/rust/issues/54378 [3]: https://github.com/rust-lang/rust/issues/54895 https://github.com/rust-lang/rust/issues/54895

zaarn 8y ago

>Those things the compiler is angry about? Those are things that would be runtime errors in C. I'm very very aware of that though this is not always true. For example Rust doesn't have a sane way to have a reentrant mutex without including std, which is bad because for interrupts in a kernel you need to either have very fine grained locking and fallbacks or rely entirely on lockless operations. Interrupts can occur on top of eachother in which case it behave a lot worse than simply being reentrant. rustc yells at me a lot for the solutions this requires because the way I solve it violates ownership rules of rust the hard way to make the code simpler and understandable. Other times it's when for bizarre reason rust wants the code to implement the Sync and Send traits despite the kernel running alone on the core (there is no threading in that kernel) and I would love to be able to tell rustc to just shut up about this and simply ignore Send, possibly even Sync, on a module level.

richardwhiuk 8y ago
Linux's kernel runs on more than one core and is pre-emptible, so that's just not generally true.
- zaarn 8y ago
  In the context of a single core, this happens. Multiple cores make it harder because on top of an interrupt taking locks, other cores now also take locks and you can no longer rely on various promises that a single core gives you. While the Linux kernel can do this, it's not easy to write from scratch, especially because Linux is in C so the compiler doesn't complain about weird things you do.
steveklabnik 8y ago
If you know your types are Send and Sync, then you should implement Send and Sync for them. That's how you "tell rustc to just shut up about this."
- zaarn 8y ago
  They aren't Send and Sync, ie not multithreading safe, they are however, reentrant safe, which is all I need. rustc complaints and I don't want to implement traits on types that don't need them and don't adhere to the contract of the trait.
pcwalton 8y ago
You shouldn't have to worry about Send and Sync if you aren't using generic types that require that their type parameters be Send and Sync. What such types are you using?
- zaarn 8y ago
  Various no_std libs use Send+Sync in places which makes things fun. Another would be static mutable variables, which are perfectly safe in a single-threaded environment, doubly so if you map that memory on a per-core basis to ensure each kernel has a unique variable value. Esp if you need lazy_static then there aren't many options other than wrapping the data in a mutex for no good reason.

mehrdadn 8y ago

> Those things the compiler is angry about? Those are things that would be runtime errors in C. > There is a subset of "valid" Rust code that `rustc` rejects because it isn't smart enough to understand it would be safe Way to tell him he's wrong only to then proceed to directly contradict yourself...

estebank 8y ago
> [...] but I would guess that those cases are less common than than the cases of "seemingly valid" Rust code that is in reality problematic if it were accepted. I would guess that most people starting to try out Rust are hitting the latter more often than the former. "Valid" Rust code that `rustc` rejects is uncommon (and for the most part, a bug), but wanted to acknowledge it happens. A "common" case of it would self-referencing structs, but that is considered a bug to be solved. I've only personally experienced problems with valid code being rejected when expressing complex trees involving associated types with their own independent lifetimes[1][2][3]. [1]: https://github.com/rust-lang/rust/issues/55756 https://github.com/rust-lang/rust/issues/55756 [2]: https://github.com/rust-lang/rust/issues/54378 https://github.com/rust-lang/rust/issues/54378 [3]: https://github.com/rust-lang/rust/issues/54895 https://github.com/rust-lang/rust/issues/54895