5 ms·

C and C++ are not a very thin abstraction over assembly language. The C virtual machine is very far from the actual hardware. And Rust is the same distance from

C and C++ are not a very thin abstraction over assembly language. The C virtual machine is very far from the actual hardware. And Rust is the same distance from the hardware as C and C++ are. Rust's core operations are, by and large, the same simple mapping to LLVM instructions. I don't find the idea of a new non-memory-safe C replacement in 2022 very exciting. We should be moving away as an industry from non-memory-safe languages, for the obvious security and productivity reasons.

skohan 5y ago
I don't see how you could argue that C is comparable in terms of level of abstraction to Rust and C++. For instance with Rust memory management is totally abstracted away from you as the programmer, which is a core part of what a computer is doing. And if you index into an array in C, that's basically like saying `root memory location + stride * index`. In Rust it's calling a trait function which could be doing arbitrary work. Rust and C++ are on similar levels of abstraction, but C is much, much simpler.
- pcwalton 5y ago
  How is Rust memory management totally abstracted away from you? You have to opt in to every heap allocation, just as you have to call malloc() in C. And it's certainly true that Rust has overloading and C doesn't, but that wasn't what I was getting at. The point is that C is defined in terms of the C virtual machine, not the underlying hardware. The C virtual machine is quite far from the actual CPU instructions.
  - skohan 5y ago
    In Rust you opt into every heap allocation with an abstraction like Rc, Arc, Box etc. With C you would have to implement each of those behaviors with primitives, because C is at a lower level of abstraction than Rust.
    - djur 5y ago
      malloc is also an abstraction.
      - skohan 5y ago
        I never said C is without abstraction, only that it is a relatively thin abstraction. Are you seriously arguing that Rust is not at a higher level of abstraction than C?
        littlestymaar 5y ago
        > Are you seriously arguing that Rust is not at a higher level of abstraction than C? Rust is clearly not at a higher level of abstraction than C++, yet in your own argument you've put C and C++ on the same ground…
        skohan 5y ago
        No I haven't. I said Rust and C++ are on similar levels of abstraction.
        littlestymaar 5y ago
        Yet a few comments above in this thread[1]: > I feel it's missing the quality from C/C++ that they are a very thin abstraction over assembly. [1]: https://news.ycombinator.com/item?id=30419248 https://news.ycombinator.com/item?id=30419248
        skohan 5y ago
        I also said this: > Rust and C++ are on similar levels of abstraction, but C is much, much simpler.
    - littlestymaar 5y ago
      How is that different from C++? Since you've explicitly put C and C++ in the same basket, this argument doesn't hold any water…
inkyoto 5y ago
> C and C++ are not a very thin abstraction over assembly language We can argue the thinkness (or the thinness) of the abstraction until cows come home, but while (*dst++ = *src++) ; is a direct abstraction over L1: movb @(r0)+, @(r1)+ tstb (r0) bne L1 (assuming «src» and «dst» are both «char *» and addresses are loaded into «r1» and «r0» registers, consequently) in the PDP-11 architecture that C was designed on and for. The instruction sequence is exactly 4x 16 bit words long. As well as *ptr &= 1; becoming and #1, (r0) and being 2x 16 bit word instruction (assuming «ptr» is an «int *» and is loaded into «r0»). Pointer arithmetic and array design in C as we know them today was highly influenced by the addressing modes existing in the PDP-11 ISA, with many C abstractions having to a direct correspondence to specific sequences of PDP-11 instructions. C++ is much less of a hardware abstraction, specifically when it comes to the higher level language features.
- pjmlp 5y ago
  Except that breaks outside non PDP-11 CPU, where many languages offer the same "low level" capabilities of C. Or 8 bit CPUs like 6502 and Z80 that aren't even able to fully support C.
  - inkyoto 5y ago
    6502 and Z80 had not existed yet when C was begot for the PDP-11 architecture. Yes – historically – C has never been a perfect fit for 8-bit architectures as it had been conceived for a 16-bit architecture. So what? There are C compilers for 68HC08 68HC11 MCU's as well. Yet, C has outlived «many languages offering the same "low level" capabilities of C».
    - deleted 5y ago
      [deleted]
    - pjmlp 5y ago
      The reasons for its survival cross many axis, it wasn't just for the language alone on its own.
- 5y ago

skohan 5y ago

I don't see how you could argue that C is comparable in terms of level of abstraction to Rust and C++. For instance with Rust memory management is totally abstracted away from you as the programmer, which is a core part of what a computer is doing. And if you index into an array in C, that's basically like saying `root memory location + stride * index`. In Rust it's calling a trait function which could be doing arbitrary work. Rust and C++ are on similar levels of abstraction, but C is much, much simpler.

pcwalton 5y ago
How is Rust memory management totally abstracted away from you? You have to opt in to every heap allocation, just as you have to call malloc() in C. And it's certainly true that Rust has overloading and C doesn't, but that wasn't what I was getting at. The point is that C is defined in terms of the C virtual machine, not the underlying hardware. The C virtual machine is quite far from the actual CPU instructions.
- skohan 5y ago
  In Rust you opt into every heap allocation with an abstraction like Rc, Arc, Box etc. With C you would have to implement each of those behaviors with primitives, because C is at a lower level of abstraction than Rust.
  - djur 5y ago
    malloc is also an abstraction.
    - skohan 5y ago
      I never said C is without abstraction, only that it is a relatively thin abstraction. Are you seriously arguing that Rust is not at a higher level of abstraction than C?
      - littlestymaar 5y ago
        > Are you seriously arguing that Rust is not at a higher level of abstraction than C? Rust is clearly not at a higher level of abstraction than C++, yet in your own argument you've put C and C++ on the same ground…
        skohan 5y ago
        No I haven't. I said Rust and C++ are on similar levels of abstraction.
        littlestymaar 5y ago
        Yet a few comments above in this thread[1]: > I feel it's missing the quality from C/C++ that they are a very thin abstraction over assembly. [1]: https://news.ycombinator.com/item?id=30419248 https://news.ycombinator.com/item?id=30419248
        skohan 5y ago
        I also said this: > Rust and C++ are on similar levels of abstraction, but C is much, much simpler.
  - littlestymaar 5y ago
    How is that different from C++? Since you've explicitly put C and C++ in the same basket, this argument doesn't hold any water…

inkyoto 5y ago

> C and C++ are not a very thin abstraction over assembly language We can argue the thinkness (or the thinness) of the abstraction until cows come home, but while (*dst++ = *src++) ; is a direct abstraction over L1: movb @(r0)+, @(r1)+ tstb (r0) bne L1 (assuming «src» and «dst» are both «char *» and addresses are loaded into «r1» and «r0» registers, consequently) in the PDP-11 architecture that C was designed on and for. The instruction sequence is exactly 4x 16 bit words long. As well as *ptr &= 1; becoming and #1, (r0) and being 2x 16 bit word instruction (assuming «ptr» is an «int *» and is loaded into «r0»). Pointer arithmetic and array design in C as we know them today was highly influenced by the addressing modes existing in the PDP-11 ISA, with many C abstractions having to a direct correspondence to specific sequences of PDP-11 instructions. C++ is much less of a hardware abstraction, specifically when it comes to the higher level language features.

pjmlp 5y ago
Except that breaks outside non PDP-11 CPU, where many languages offer the same "low level" capabilities of C. Or 8 bit CPUs like 6502 and Z80 that aren't even able to fully support C.
- inkyoto 5y ago
  6502 and Z80 had not existed yet when C was begot for the PDP-11 architecture. Yes – historically – C has never been a perfect fit for 8-bit architectures as it had been conceived for a 16-bit architecture. So what? There are C compilers for 68HC08 68HC11 MCU's as well. Yet, C has outlived «many languages offering the same "low level" capabilities of C».
  - deleted 5y ago
    [deleted]
  - pjmlp 5y ago
    The reasons for its survival cross many axis, it wasn't just for the language alone on its own.
5y ago