On Thursday, 5 January 2023 at 20:24:07 UTC, Alexandru Militaru wrote:
> Hi everyone,
>
> If you remember the "D for a @safer Linux Kernel“ talk from DConf 2019 [1], then you might want to read our paper [2] on that matter that was just published in IEEE Access Journal.
>
> There's also an ongoing discussion about it on Hacker News in case someone is interested [3].
>
> Cheers,
> Alexandru
>
> [1]  https://youtu.be/weRSwbZtKu0
> [2] https://ieeexplore.ieee.org/document/9987502
> [3] https://news.ycombinator.com/item?id=34260355

nice work. and an interesting read. well done for getting it published!

btw. Linus one said, more or less, that one reason he likes C so much, is because when he is typing it, he can visualise what assembly will be produced (i.e. his mind is always intune with the code the machine will actually run).

I wonder if he could every say the same about D code though (that's a question).

On Fri, Jan 06, 2023 at 04:07:12AM +0000, areYouSureAboutThat via Digitalmars-d-announce wrote: [...]
> btw. Linus one said, more or less, that one reason he likes C so much, is because when he is typing it, he can visualise what assembly will be produced (i.e. his mind is always intune with the code the machine will actually run).

That has stopped being true for at least a decade or more. C was designed to map well to the PDP-11's instruction set; modern CPU's are completely different beasts with out-of-order execution, cache hierarchy, multi-core, multi-thread per core, expanded instruction sets, and microcode. Why do you think, for example, that in the kernel functions and intrinsics are used for certain CPU-specific instructions? Because nothing in C itself corresponds to them.  The closeness of C to the CPU is only an illusion.


T

-- 
Don't get stuck in a closet---wear yourself out.

On Friday, 6 January 2023 at 04:07:12 UTC, areYouSureAboutThat wrote:
>
> btw. Linus one said, more or less, that one reason he likes C so much, is because when he is typing it, he can visualise what assembly will be produced (i.e. his mind is always intune with the code the machine will actually run).
>
> I wonder if he could every say the same about D code though (that's a question).

btw. Just in case I misquoted him, I found the link:

https://www.youtube.com/watch?v=CYvJPra7Ebk

On Friday, 6 January 2023 at 11:02:03 UTC, Tejas wrote:
>
> Those statements, even if spoken recently, are just a way of maintaining PR. Elon also similarly calls C++ a bloated mess and that all high performance code at Tesla is in C, as if that's something to be proud of... their ultra safety critical software project being built using a very much unsafe-by-defualt-for-everything language...
>
>
> Nvidia made a good decision to use ADA/SPARK, IMO

Well, the worlds most widely used source code revision control system, is written in C ;-)

The C language is not the problem, and I'm unable to accept the assertion in the paper, that 'C was designed to allow unsafe memory operations'. That is a red herring.

In fact, C can be used in a perfectly memory safe manner.

The problem is that too few programmers know how to do that, and even very experienced C programmers can get it wrong sometimes. Both tools and compilers have come along way over the last decade, and it's getting increasingly 'harder' to write memory unsafe C, but in the end, in C, its the programmer that has the control.

That is  what the paper should have asserted instead of that red herring.

What the paper is really asserting, is that this control needs to be taken away (at least to some point) from the programmer.

But C will always be the language that gives the programmer the flexibilty and control needed, when all the other languages will not.

Other languages often claim to be 'C like', but that's mostly syntax related.

To be 'C like', the language needs to provide the same flexibility and control as C, and map to the hardware and its instructions set as well as C. In other words, it's going to end up being C anyway.

On Saturday, 7 January 2023 at 23:27:02 UTC, Siarhei Siamashka wrote:
>
> There are attempts to rewrite it in safer programming languages ;-) Such as https://github.com/Byron/gitoxide

I'd love to hear Lord Linus's thought on this.

> Let's see if the alternative implementations turn out to be good enough and allow to eventually retire C at least for this particular task. Survival for the fittest.
>

Yes, as you say, 'survival of the fittest' also applied in programming languages ;-)

That certainly says something about C.

> Doesn't the D code annotated as `@system` already provide the same flexibility and control as C? If not, then what is missing?

What missing, is that 'still' nothing has come close to replacing C.

Yes, this paper makes a compelling case to look more closely at D.

But could it replace C?

I don't see that ever happening (in my lifetime).

C is not just a programming language anymore. It's a complete (and very diverse) ecosystem.

C 'replacement wannabees', have to compete with both.

The only way I see C being replaced, is if all the C programmers retire, or RIP, and don't sufficiently get replaced with new ones.