No it really isn't. Newbies struggle with pointers all the time, before they even get to the question of pointer lifetime and what is and what is not safe pointer arithmetic.
> "C with X"
I think the most interesting areas here are Zig and D, although I'm not too familiar with them myself.
Really what we want is an end to "can't spell CVE without C": a language which makes it as difficult as possible to write software which can be compromised remotely.
I was coming from Pascal but hardest to grok were not pointers but that everything in C is an expression possibly with side effects. Unlike Pascal statements.
The problem is that we also need a language that makes it easy to write the software in the first place.
I'm still sceptical that Rust is this language. It is a somewhat successful languages with lots of people tinkering around, and some mildly successful software (what is the most successful software written in it, btw?). But in a team I'm working in (doing a distributed filesystem), there was an effort do bring Rust into the team and it still isn't easy to gain adoption in the team after a few years. And this is partly credited due to the difficulty of writing in the language.
What I suspect is that a lot of the success is explained by the tooling around the language, making it very easy (especially compared to C) to rely on existing infrastructure. But not necessarily that this infrastructure is particularly easy to write or maintain.
> what is the most successful software written in it, btw?
Depends on how you define successful, but I’d probably put money on it being “whataver the few million lines inside of Facebook are doing” or “the few million (probably, I don’t actually know on this one) lines inside of Amazon that they say powers S3, EC2, and CloudFront. Might be the various CloudFlare products, given how likely a given GET request is to touch their infrastructure.
I sometimes think we'd be better off with a "typesafe macro assembler" for some of the C uses. People keep using C for this when it really isn't, and then get kicked in the face by UB/optimizer interactions deleting security critical code.
LLVM IR is an acceptable meta-assembler for most purposes. The degree to which it's used directly is roughly the degree to which people find that sort of tool useful, and it is used directly to some degree.
It would be a worthy project to write a language with the goal of providing the minimum affordances to LLVM IR to make it pleasant to program in, without fully obscuring what you're doing. I'd play around with it.
Yes, djb wanted a C flavour with no UB. That could also work. A macro assembler could fall behind optimizations, but a C with no UB could still optimize pretty well I reckon. Maybe there is a small market for an optimized language with no UB.
"No UB" is really hard to do without sacrificing some portability. It took C decades to specify that arithmetic was twos-complement, for example. However "UB means the optimizer is free to change the semantics on the assumption that you don't hit UB" is a huge source of surprises.
No it really isn't. Newbies struggle with pointers all the time, before they even get to the question of pointer lifetime and what is and what is not safe pointer arithmetic.
> "C with X"
I think the most interesting areas here are Zig and D, although I'm not too familiar with them myself.
Really what we want is an end to "can't spell CVE without C": a language which makes it as difficult as possible to write software which can be compromised remotely.