> 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.

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.

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».

The reasons for its survival cross many axis, it wasn't just for the language alone on its own.

It really was an elegant instruction set.

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.

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.

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.

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…

It sees like you're trying to catch me with some kind of gotcha instead of dealing with the argument in good faith.

malloc is also an abstraction.

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?

> 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…

No I haven't. I said Rust and C++ are on similar levels of abstraction.

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

I also said this:

> Rust and C++ are on similar levels of abstraction, but C is much, much simpler.