7 ms·

C is not the new assembly. This line has been reused for years, even decades. And it has always been a lie. Memory safety and automatic memory management come

C is not the new assembly. This line has been reused for years, even decades. And it has always been a lie. Memory safety and automatic memory management come at a cost. Even in Rust. C will always have a use for critical performance in the embedded world.

random314 7y ago
Can you show some sample code in Rust with this memory management cost that C doesn't have?
atoav 7y ago
I am pretty sure the article didn't claim that C won't always have it's place – alone for all the existing codebases it makes sense to use it. If people still learn latin many centuries after the fall of Rome, why would they ever stop to deal with C? I am somebody who uses C on embedded but really likes the way Rust does things too. Sometimes my naive Rust implementations outperformed my optimized C code very easilly (maybe I am not good enough, who knows). What I especially liked are the zero cost abstractions, which allows you to keep that cost you were talking about very low. And if I like to do stuff on my own I just do it inside an unsafe block and I am very close to what I could/would do in C. Even if Rust would fade away it teached me a few hard lessons that definitly improved my C programming.
- codesushi42 7y ago
  That is fair. I am responding to the click baity title of the article. C has been declared dead and replaced so many times over the years that I have lost count. It is not going to be replaced enitrely by Rust, and definitely not in the embedded world. C will not be the new assembly, it will continue to be C. C++ could be an entirely different story.
  - pjmlp 7y ago
    C will be replaced, as soon at the last dev that keeps religiously using C89 with language extensions retires.
adrianN 7y ago
What's the cost? If you're not afraid of `unsafe`, you can do in Rust exactly the same stuff you do in C, while still having strong guarantees for all your safe code. You might argue that fighting the borrow checker has development costs, but the memory issues that it prevents also have a development cost.
kllrnohj 7y ago
> C will always have a use for critical performance in the embedded world. Based off of what reasoning? It's not like C is any faster or more efficient than Rust or C++. Heck you can often go faster in C++/Rust than you can in C thanks to the ease of using abstractions that just make things go-faster for you automatically (such as SSO in things like strings, or constexpr for compile-time resolution). The embedded world isn't using C because it's a good fit, they are using it because of legacy inertia and lack of motivation to move to anything else. IoT is starting to change that, as all those C memory vulnerability issues turn into product support costs. And also realistically embedded isn't even restricted to C already. Very popular microcontrollers like the esp8266 or esp32 also have javascript runtimes.
- codesushi42 7y ago
  It's not like C is any faster or more efficient than Rust or C++ Huh? C is certainly faster than C++. go-faster for you automatically (such as SSO in things like strings, or constexpr for compile-time resolution). That is a terrible example. You shouldn't be using the STL (i.e. std::string copying) for performance critical sections to begin with. Very popular microcontrollers like the esp8266 or esp32 also have javascript runtimes. First, esps are not low end microcontrollers at all. Second, no one uses JS runtimes for performance critical code on microcontrollers (e.g. JS will not give you direct memory access). What an absurd claim.
  - pjmlp 7y ago
    In what benchmarks?!?
    - codesushi42 7y ago
      Virtual functions, runtime type information, STL, larger executable code size, etc... Memory footprint will be smaller on C without using C++ abstractions. Which is important for embedded systems.
      - pjmlp 7y ago

random314 7y ago

Can you show some sample code in Rust with this memory management cost that C doesn't have?

atoav 7y ago

I am pretty sure the article didn't claim that C won't always have it's place – alone for all the existing codebases it makes sense to use it. If people still learn latin many centuries after the fall of Rome, why would they ever stop to deal with C? I am somebody who uses C on embedded but really likes the way Rust does things too. Sometimes my naive Rust implementations outperformed my optimized C code very easilly (maybe I am not good enough, who knows). What I especially liked are the zero cost abstractions, which allows you to keep that cost you were talking about very low. And if I like to do stuff on my own I just do it inside an unsafe block and I am very close to what I could/would do in C. Even if Rust would fade away it teached me a few hard lessons that definitly improved my C programming.

codesushi42 7y ago
That is fair. I am responding to the click baity title of the article. C has been declared dead and replaced so many times over the years that I have lost count. It is not going to be replaced enitrely by Rust, and definitely not in the embedded world. C will not be the new assembly, it will continue to be C. C++ could be an entirely different story.
- pjmlp 7y ago
  C will be replaced, as soon at the last dev that keeps religiously using C89 with language extensions retires.

adrianN 7y ago

What's the cost? If you're not afraid of `unsafe`, you can do in Rust exactly the same stuff you do in C, while still having strong guarantees for all your safe code. You might argue that fighting the borrow checker has development costs, but the memory issues that it prevents also have a development cost.

kllrnohj 7y ago

> C will always have a use for critical performance in the embedded world. Based off of what reasoning? It's not like C is any faster or more efficient than Rust or C++. Heck you can often go faster in C++/Rust than you can in C thanks to the ease of using abstractions that just make things go-faster for you automatically (such as SSO in things like strings, or constexpr for compile-time resolution). The embedded world isn't using C because it's a good fit, they are using it because of legacy inertia and lack of motivation to move to anything else. IoT is starting to change that, as all those C memory vulnerability issues turn into product support costs. And also realistically embedded isn't even restricted to C already. Very popular microcontrollers like the esp8266 or esp32 also have javascript runtimes.

codesushi42 7y ago
It's not like C is any faster or more efficient than Rust or C++ Huh? C is certainly faster than C++. go-faster for you automatically (such as SSO in things like strings, or constexpr for compile-time resolution). That is a terrible example. You shouldn't be using the STL (i.e. std::string copying) for performance critical sections to begin with. Very popular microcontrollers like the esp8266 or esp32 also have javascript runtimes. First, esps are not low end microcontrollers at all. Second, no one uses JS runtimes for performance critical code on microcontrollers (e.g. JS will not give you direct memory access). What an absurd claim.
- pjmlp 7y ago
  In what benchmarks?!?
  - codesushi42 7y ago
    Virtual functions, runtime type information, STL, larger executable code size, etc... Memory footprint will be smaller on C without using C++ abstractions. Which is important for embedded systems.
    - pjmlp 7y ago