7 ms·

Rust isn't viable for embedded platforms, at least not yet. It's not as easy to compile it to the most obscure ISAs as C, and the little support it has for stuf

Rust isn't viable for embedded platforms, at least not yet. It's not as easy to compile it to the most obscure ISAs as C, and the little support it has for stuff like STM32 is restricted to just that group of microcontrollers and doesn't support the entire ARM range. Maybe in the future? I'm looking forward to that day! Go is probably never going to run on microcontrollers due to its very big overhead. C perfectly matches on top of the hardware of a processor. Every single design decision about C was made with the computer in mind. Memory, pointers, stack, call stack, returns, arguments, just everything is so excellently designed. Even Linus Torvalds says so! https://www.youtube.com/watch?v=CYvJPra7Ebk https://www.youtube.com/watch?v=CYvJPra7Ebk If I were to make one change to C, it would be to completely rip out the #include system and bring a proper modules system. Apart from that, it's pretty much perfect.

manfredo 7y ago
> Go is probably never going to run on microcontrollers due to its very big overhead. My employer runs go on micro controllers. Definitely suboptimal, but as long as the cost of increasing hardware capacity to accommodate Go is feasible then it's a viable option.
- jason0597 7y ago
  Isn't it counter productive to go out of your way to find better hardware to fit your language choice? Why not choose a lighter language?
  - manfredo 7y ago
    Libraries might be easier to use, and you can use the same language on the server and hardware.
totalperspectiv 7y ago
TinyGo recently became an official project and seems extremely successful.
zenhack 7y ago
> Every single design decision about C was made with the computer in mind. The only problem is that computers have changed a bit in the last 50 years, and C largely hasn't. There are a couple issues: First, C was designed for single-pass compilers, because the PDP-7 it was designed for was too small to actually run much fancier of a compiler. So C is seriously sub-optimal for optimization in a lot of ways (because the assumption was you weren't going to do compiler optimizations anyway), and there are some user-visible warts like forward declarations that are completely unnecessary today. Second, the relevant questions with regard to CPU performance have changed a lot. Most notably: - CPU performance has completely outstripped memory perf, so memory hierarchies and locality are everything - Parallelism everywhere. Multiple cores, but also deeper instruction pipelines and other such things. The way those things map to C is completely implicit; they don't show up in the language at all, and getting the machine to do what you want requires knowing things that the code wouldn't suggest at all. I think if the same people had designed a language for a similar niche today's hardware, a lot of things would be different.
- ori_b 7y ago
  > The only problem is that computers have changed a bit in the last 50 years, and C largely hasn't. There are a couple issues: The problem with this line of argument: assembly has also not changed. If the things you talk about mattered, we would be using a different assembly.
  - fctorial 7y ago
    > we would be using a different assembly. We are. It's called microcode.
    - ori_b 7y ago
      And, you write microcode?
- nomel 7y ago
  > CPU performance has completely outstripped memory perf, so memory hierarchies and locality are everything > they don't show up in the language at all... requires knowing things that the code wouldn't suggest at all I'm utterly confused at this. It's trivial to layout memory as you please, where you please, very directly, in C. Set a pointer to and address and write to it. Better yet, I can define a packed struct that maps to a peripheral, point it to its memory address from a data sheet, and have a nice human readable way of controlling it: MyPIECDevice.sample_rate = 2000. Keeping things physically close in memory has always been a strong requirement, as long as cache, pages, and larger than one-byte-memory buses have existed.
anonsivalley652 7y ago
> Rust isn't viable for embedded platforms, at least not yet. no_std allows the important hooks of panicking, output and allocation to be implemented by the user. It's also very easy to put in hard-coded pointers that represent memory-mapped hardware. And there's no GC. Furthermore, it's entirely possible to convert only a portion of a project to using Rust while working to gradually to replace/reimplement. > If I were to make one change to C, it would be to completely rip out the #include system [preprocessor] and bring a proper modules system. Congratulations, you've just reinvented Java, D, Rust and Go. > Apart from that, it's pretty much perfect. This seems like a religious opinion rather than having understanding of different paradigms. Have you been paying attention to why Java, Erlang, Go, Rust and exist? Rust has numerous advantages over C that eliminate entire categories of problems without sacrificing speed. If you can't see that, then maybe you don't want to see it.
billfruit 7y ago
While it is true that C perfectly matches the hardware, it imperfectly matches the rich software abstractions which are needed for moderate and large software. The lack of namespaces, sane object creation, destruction features etc, makes programming tedious. A large proportion of code in many large C programs go into recreating imperfectly the features that are by default provided by richer programming systems, and that repeats for every large program you do. It quickly becomes boring and unenlightening, to recreate an exception handling mechanism or data structure implementation for the nth time. Why would anyone not prefer not having to focus on the mere infrastructure, and rather direct directions on the interesting problems to be solved. Another thing is that large C code bases tend to become ensconced in layers of preprocessor macros, which I think is a hack-y way of doing things.
sedachv 7y ago
> Every single design decision about C was made with the computer in mind. A computer. The PDP-11. C was a terrible fit for a lot of the popular contemporary architectures when it was designed (PDP-10, Burroughs large systems, UNIVAC 1100, CDC mainframes, HP 3000), and continued to be a very poor fit for many computers in the 1980s (segmented 8086 and 286, 6502, AS/400, Lisp Machines except for Xerox, Connection Machine, Tandem, Novix/RTX, Transputer, etc.).

manfredo 7y ago

> Go is probably never going to run on microcontrollers due to its very big overhead. My employer runs go on micro controllers. Definitely suboptimal, but as long as the cost of increasing hardware capacity to accommodate Go is feasible then it's a viable option.

jason0597 7y ago
Isn't it counter productive to go out of your way to find better hardware to fit your language choice? Why not choose a lighter language?
- manfredo 7y ago
  Libraries might be easier to use, and you can use the same language on the server and hardware.

totalperspectiv 7y ago

TinyGo recently became an official project and seems extremely successful.

zenhack 7y ago

> Every single design decision about C was made with the computer in mind. The only problem is that computers have changed a bit in the last 50 years, and C largely hasn't. There are a couple issues: First, C was designed for single-pass compilers, because the PDP-7 it was designed for was too small to actually run much fancier of a compiler. So C is seriously sub-optimal for optimization in a lot of ways (because the assumption was you weren't going to do compiler optimizations anyway), and there are some user-visible warts like forward declarations that are completely unnecessary today. Second, the relevant questions with regard to CPU performance have changed a lot. Most notably: - CPU performance has completely outstripped memory perf, so memory hierarchies and locality are everything - Parallelism everywhere. Multiple cores, but also deeper instruction pipelines and other such things. The way those things map to C is completely implicit; they don't show up in the language at all, and getting the machine to do what you want requires knowing things that the code wouldn't suggest at all. I think if the same people had designed a language for a similar niche today's hardware, a lot of things would be different.

ori_b 7y ago
> The only problem is that computers have changed a bit in the last 50 years, and C largely hasn't. There are a couple issues: The problem with this line of argument: assembly has also not changed. If the things you talk about mattered, we would be using a different assembly.
- fctorial 7y ago
  > we would be using a different assembly. We are. It's called microcode.
  - ori_b 7y ago
    And, you write microcode?
nomel 7y ago
> CPU performance has completely outstripped memory perf, so memory hierarchies and locality are everything > they don't show up in the language at all... requires knowing things that the code wouldn't suggest at all I'm utterly confused at this. It's trivial to layout memory as you please, where you please, very directly, in C. Set a pointer to and address and write to it. Better yet, I can define a packed struct that maps to a peripheral, point it to its memory address from a data sheet, and have a nice human readable way of controlling it: MyPIECDevice.sample_rate = 2000. Keeping things physically close in memory has always been a strong requirement, as long as cache, pages, and larger than one-byte-memory buses have existed.

anonsivalley652 7y ago

> Rust isn't viable for embedded platforms, at least not yet. no_std allows the important hooks of panicking, output and allocation to be implemented by the user. It's also very easy to put in hard-coded pointers that represent memory-mapped hardware. And there's no GC. Furthermore, it's entirely possible to convert only a portion of a project to using Rust while working to gradually to replace/reimplement. > If I were to make one change to C, it would be to completely rip out the #include system [preprocessor] and bring a proper modules system. Congratulations, you've just reinvented Java, D, Rust and Go. > Apart from that, it's pretty much perfect. This seems like a religious opinion rather than having understanding of different paradigms. Have you been paying attention to why Java, Erlang, Go, Rust and exist? Rust has numerous advantages over C that eliminate entire categories of problems without sacrificing speed. If you can't see that, then maybe you don't want to see it.

billfruit 7y ago

While it is true that C perfectly matches the hardware, it imperfectly matches the rich software abstractions which are needed for moderate and large software. The lack of namespaces, sane object creation, destruction features etc, makes programming tedious. A large proportion of code in many large C programs go into recreating imperfectly the features that are by default provided by richer programming systems, and that repeats for every large program you do. It quickly becomes boring and unenlightening, to recreate an exception handling mechanism or data structure implementation for the nth time. Why would anyone not prefer not having to focus on the mere infrastructure, and rather direct directions on the interesting problems to be solved. Another thing is that large C code bases tend to become ensconced in layers of preprocessor macros, which I think is a hack-y way of doing things.

sedachv 7y ago

> Every single design decision about C was made with the computer in mind. A computer. The PDP-11. C was a terrible fit for a lot of the popular contemporary architectures when it was designed (PDP-10, Burroughs large systems, UNIVAC 1100, CDC mainframes, HP 3000), and continued to be a very poor fit for many computers in the 1980s (segmented 8086 and 286, 6502, AS/400, Lisp Machines except for Xerox, Connection Machine, Tandem, Novix/RTX, Transputer, etc.).