6 ms·

Genuine question. With Rust and C++, even for embedded systems, what is the use case for starting a new project that does binary encoding and network with such

by omeid2 3y ago

Genuine question. With Rust and C++, even for embedded systems, what is the use case for starting a new project that does binary encoding and network with such an unsafe language like C? I find it almost inexcusable at this point.

VikingCoder 3y ago
From the website, "It has been developed continuously since 2010".
synergy20 3y ago
whatever software you're using, including HN the site, nearly all boil down to C at the bottom, C is fine, now and in the future.
- omeid2 3y ago
  If we are playing that game, why stop there? why not ASM? Better yet, why don't you be a real developer and use a magnet?
  - megous 3y ago
    Because most people want portable programs, whithout having to rewrite them for each target. C helps a lot in this respect, compared to assembly.
    - omeid2 3y ago
      Go on then, tell me which platform you can't use Rust or at least C++ when you can use C with standard library?
      - megous 3y ago
        Why would I do it? You compared C to asm, not rust.
      - throwawayEmb 3y ago
        Not sure what you mean by “with standard library”, but STM8 has no C++ or Rust compiler that I know of. For other MCUs where you do get C++ support, you often only get C++98. Replied to your other comment about this as well.
        omeid2 3y ago
        You're not going to be able to run Libwebsockets on STM8, so not sure why that platfrom matters? Also, if you're not sure what “with standard library” in the context of C programming means, start here: https://en.wikipedia.org/wiki/C_standard_library https://en.wikipedia.org/wiki/C_standard_library
        throwawayEmb 3y ago
        Perhaps I read your statement too literally. If we are only talking about targets able to run libwebsockets unmodified, STM8 is of course irrelevant. That assumption was not clear to me though. Many embedded code bases do not have a 100% standard-conforming libc and e.g. miss I/O functions like fopen and friends (because there is no file system). And at that level, you will sometimes only get compilers for C (or older C++ dialects).
Gow8876 3y ago
You can consider translating this library to Rust. As long as you can't or don't have the time commitment, we take this one over some fable or cool new library somewhere. This one has 13 years proven battlefield use. Any big bugs already iron out or at least not so obvious. Rust may have safe memory coding built-in, it doesnt guarantee the coding to be 100% bug free or fully secure from zero day attacks. This is even worst off when the library say written in Rust just come out less than a couple years or even 6 mths.
- omeid2 3y ago
  > You can consider translating this library to Rust. There is no need for it. Rust already has libraries for http, websockets, and mqtt. > This one has 13 years proven battlefield use. And by lord this myth of "Old therefore must be battle-tested" must die. Case in appoint, I had to interact with a piece of software that used this library and it is as battle-tested as expecting HTTP headers in very specific casing! Here is a comment from some code I wrote circa 2020 to deal with this issue. So it is not hypothetical. // libwebsocket/1.X.X is naive about http headers // and expects them in a specific case but node.js as // permitted by http spec doesn't care about case. // this patches node.js http to send headers as expected // by libwebsocket/VAA const { setHeader } = http.OutgoingMessage.prototype; http.OutgoingMessage.prototype.setHeader = function (name, value) { name = name .replace(/\b(\w)/g, (match, submatch) => (submatch ? submatch.toUpperCase() : '')) .replace(/(websocket|Websocket)/g, () => 'WebSocket'); value = value.replace(/(websocket|Websocket)/g, () => 'WebSocket'); setHeader.call(this, name, value); };
  - lelanthran 3y ago
    >>> With Rust and C++, even for embedded systems, what is the use case for starting a new project that does binary encoding and network with such an unsafe language like C? >> Rust may have safe memory coding built-in, it doesnt guarantee the coding to be 100% bug free or fully secure from zero day attacks. > Case in appoint, I had to interact with a piece of software that used this library and it is as battle-tested as expecting HTTP headers in very specific casing! How would rewriting in $SOMETHING_OTHER_THAN_C help with this bug? This is a bug that would have happened in any language. After all, Gow8876 was very specific about what he was referring to ("memory safety" bugs), because you were very specific about what you were referring to ("unsafe language").
lelanthran 3y ago
> what is the use case for starting a new project that does binary encoding and network with such an unsafe language like C? *Shrug* Some people prefer simplicity. > I find it almost inexcusable at this point. C has been deployed, since the 80s, in millions upon millions of life-critical systems with loss of human life due to C-specific errors close to zero. It's fascinating that you think that, until Rust (or modern C++ came along), people were being killed in significant numbers due to C-specific errors.
israrkhan 3y ago
Despite what you may think, C is still the most portable language. I can think of several embedded platforms where Rust or C++ is not even an option.
- omeid2 3y ago
  Go on, name a few.
  - throwawayEmb 3y ago
    The STM8 processor for instance has no C++ or Rust compiler to my knowledge, even though it was produced in huge volumes [1]. It is still quite common to see proprietary compiler-suites in the embedded world. Most only support C. Some do not even support C99 :) Sure for many ARM targets (e.g. Cortex series), you can use GCC or LLVM etc. and get access to C++. Many embedded shops targetting the lower end (8-32 bit CPUs <100MHz + 8-32kb RAM) prefer C for the simplicity. 1: STMicro announced back in 2016 that they’d sold more than 2 billion of these chips, so it’s not some obscure little niche processor.
    - omeid2 3y ago
      You can't run libwebsockets on STM8. You can _only_ use it anywhere you can use Linux, BSD, or FreeRTOS, which also means you can use C++ and Rust.
      - throwawayEmb 3y ago
        Anything POSIX should do, no? Anyway, I still think the point stands: many lower level targets do not have C++ or Rust compilers, but do have okay-ish C compilers. You replied to > I can think of several embedded platforms where Rust or C++ is not even an option. … asking “Go on, name a few”. I understood this as “name a few targets for which C++ and/or Rust is unavailable”. These targets do exist and are perhaps more common than you assume. In my own experience, it is mostly seen with small micros though. But perhaps I misunderstood you?
dkjaudyeqooe 3y ago
> With Rust and C++ C isn't great, but at least it's relatively simple and is well understood. What you're suggesting is a nightmare scenario.

by omeid2 3y ago

VikingCoder 3y ago

From the website, "It has been developed continuously since 2010".

synergy20 3y ago

whatever software you're using, including HN the site, nearly all boil down to C at the bottom, C is fine, now and in the future.

omeid2 3y ago
If we are playing that game, why stop there? why not ASM? Better yet, why don't you be a real developer and use a magnet?
- megous 3y ago
  Because most people want portable programs, whithout having to rewrite them for each target. C helps a lot in this respect, compared to assembly.
  - omeid2 3y ago
    Go on then, tell me which platform you can't use Rust or at least C++ when you can use C with standard library?
    - megous 3y ago
      Why would I do it? You compared C to asm, not rust.
    - throwawayEmb 3y ago
      Not sure what you mean by “with standard library”, but STM8 has no C++ or Rust compiler that I know of. For other MCUs where you do get C++ support, you often only get C++98. Replied to your other comment about this as well.
      - omeid2 3y ago
        You're not going to be able to run Libwebsockets on STM8, so not sure why that platfrom matters? Also, if you're not sure what “with standard library” in the context of C programming means, start here: https://en.wikipedia.org/wiki/C_standard_library https://en.wikipedia.org/wiki/C_standard_library
        throwawayEmb 3y ago
        Perhaps I read your statement too literally. If we are only talking about targets able to run libwebsockets unmodified, STM8 is of course irrelevant. That assumption was not clear to me though. Many embedded code bases do not have a 100% standard-conforming libc and e.g. miss I/O functions like fopen and friends (because there is no file system). And at that level, you will sometimes only get compilers for C (or older C++ dialects).

Gow8876 3y ago

You can consider translating this library to Rust. As long as you can't or don't have the time commitment, we take this one over some fable or cool new library somewhere. This one has 13 years proven battlefield use. Any big bugs already iron out or at least not so obvious. Rust may have safe memory coding built-in, it doesnt guarantee the coding to be 100% bug free or fully secure from zero day attacks. This is even worst off when the library say written in Rust just come out less than a couple years or even 6 mths.

omeid2 3y ago
> You can consider translating this library to Rust. There is no need for it. Rust already has libraries for http, websockets, and mqtt. > This one has 13 years proven battlefield use. And by lord this myth of "Old therefore must be battle-tested" must die. Case in appoint, I had to interact with a piece of software that used this library and it is as battle-tested as expecting HTTP headers in very specific casing! Here is a comment from some code I wrote circa 2020 to deal with this issue. So it is not hypothetical. // libwebsocket/1.X.X is naive about http headers // and expects them in a specific case but node.js as // permitted by http spec doesn't care about case. // this patches node.js http to send headers as expected // by libwebsocket/VAA const { setHeader } = http.OutgoingMessage.prototype; http.OutgoingMessage.prototype.setHeader = function (name, value) { name = name .replace(/\b(\w)/g, (match, submatch) => (submatch ? submatch.toUpperCase() : '')) .replace(/(websocket|Websocket)/g, () => 'WebSocket'); value = value.replace(/(websocket|Websocket)/g, () => 'WebSocket'); setHeader.call(this, name, value); };
- lelanthran 3y ago
  >>> With Rust and C++, even for embedded systems, what is the use case for starting a new project that does binary encoding and network with such an unsafe language like C? >> Rust may have safe memory coding built-in, it doesnt guarantee the coding to be 100% bug free or fully secure from zero day attacks. > Case in appoint, I had to interact with a piece of software that used this library and it is as battle-tested as expecting HTTP headers in very specific casing! How would rewriting in $SOMETHING_OTHER_THAN_C help with this bug? This is a bug that would have happened in any language. After all, Gow8876 was very specific about what he was referring to ("memory safety" bugs), because you were very specific about what you were referring to ("unsafe language").

lelanthran 3y ago

> what is the use case for starting a new project that does binary encoding and network with such an unsafe language like C? *Shrug* Some people prefer simplicity. > I find it almost inexcusable at this point. C has been deployed, since the 80s, in millions upon millions of life-critical systems with loss of human life due to C-specific errors close to zero. It's fascinating that you think that, until Rust (or modern C++ came along), people were being killed in significant numbers due to C-specific errors.

israrkhan 3y ago

Despite what you may think, C is still the most portable language. I can think of several embedded platforms where Rust or C++ is not even an option.

omeid2 3y ago
Go on, name a few.
- throwawayEmb 3y ago
  The STM8 processor for instance has no C++ or Rust compiler to my knowledge, even though it was produced in huge volumes [1]. It is still quite common to see proprietary compiler-suites in the embedded world. Most only support C. Some do not even support C99 :) Sure for many ARM targets (e.g. Cortex series), you can use GCC or LLVM etc. and get access to C++. Many embedded shops targetting the lower end (8-32 bit CPUs <100MHz + 8-32kb RAM) prefer C for the simplicity. 1: STMicro announced back in 2016 that they’d sold more than 2 billion of these chips, so it’s not some obscure little niche processor.
  - omeid2 3y ago
    You can't run libwebsockets on STM8. You can _only_ use it anywhere you can use Linux, BSD, or FreeRTOS, which also means you can use C++ and Rust.
    - throwawayEmb 3y ago
      Anything POSIX should do, no? Anyway, I still think the point stands: many lower level targets do not have C++ or Rust compilers, but do have okay-ish C compilers. You replied to > I can think of several embedded platforms where Rust or C++ is not even an option. … asking “Go on, name a few”. I understood this as “name a few targets for which C++ and/or Rust is unavailable”. These targets do exist and are perhaps more common than you assume. In my own experience, it is mostly seen with small micros though. But perhaps I misunderstood you?

dkjaudyeqooe 3y ago

> With Rust and C++ C isn't great, but at least it's relatively simple and is well understood. What you're suggesting is a nightmare scenario.