Re: Safer Linux Kernel Modules Using the D Programming Language

2023-01-07 Thread monkyyy via Digitalmars-d-announce
On Sunday, 8 January 2023 at 03:58:43 UTC, Siarhei Siamashka 
wrote:

On Sunday, 8 January 2023 at 03:18:27 UTC, monkyyy wrote:
On Sunday, 8 January 2023 at 02:15:27 UTC, areYouSureAboutThat 
wrote:


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


No progress has been made for decades but that doesn't mean 
progress is impossible.


C has a very large and diverse ecosystem exactly thanks to "no 
progress".


I was referring to all programming languages and computer science


Re: Safer Linux Kernel Modules Using the D Programming Language

2023-01-07 Thread Siarhei Siamashka via Digitalmars-d-announce

On Sunday, 8 January 2023 at 03:18:27 UTC, monkyyy wrote:
On Sunday, 8 January 2023 at 02:15:27 UTC, areYouSureAboutThat 
wrote:


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


No progress has been made for decades but that doesn't mean 
progress is impossible.


C has a very large and diverse ecosystem exactly thanks to "no 
progress". Each and every compatibility breaking change in the 
language flushes a part of the ecosystem down the toilet.


So the recipe for success is to get most of the things right from 
the very beginning (this is partly based on skill and partly 
based on luck). And then try to avoid breaking changes as much as 
possible. C language is a great example of this.


Re: Safer Linux Kernel Modules Using the D Programming Language

2023-01-07 Thread monkyyy via Digitalmars-d-announce
On Sunday, 8 January 2023 at 02:15:27 UTC, areYouSureAboutThat 
wrote:


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


No progress has been made for decades but that doesn't mean 
progress is impossible. Maybe the academia will take note that 
imperative code with goto, void* and static types are nessary and 
stop making meme language.


The unix stack was fair from prefect and the api of shells and 
stdin/out should be typed and semi graphical, hot take.


Re: Safer Linux Kernel Modules Using the D Programming Language

2023-01-07 Thread areYouSureAboutThat via Digitalmars-d-announce
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.




Re: Safer Linux Kernel Modules Using the D Programming Language

2023-01-07 Thread Siarhei Siamashka via Digitalmars-d-announce
On Saturday, 7 January 2023 at 22:25:30 UTC, areYouSureAboutThat 
wrote:
Well, the worlds most widely used source code revision control 
system, is written in C ;-)


There are attempts to rewrite it in safer programming languages 
;-) Such as https://github.com/Byron/gitoxide


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.


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.


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


Re: Safer Linux Kernel Modules Using the D Programming Language

2023-01-07 Thread areYouSureAboutThat via Digitalmars-d-announce

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.




Re: Safer Linux Kernel Modules Using the D Programming Language

2023-01-07 Thread Bastiaan Veelo via Digitalmars-d-announce
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.



[1]  https://youtu.be/weRSwbZtKu0
[2] https://ieeexplore.ieee.org/document/9987502


Kudos to you for staying on the ball on this topic. I enjoyed 
your talk back then and this article adds credibility to this 
important application of the language and addresses a wider 
audience. Well done.


Bastiaan.



Re: Good News: Almost all druntime supported on arsd webassembly

2023-01-07 Thread Guillaume Piolat via Digitalmars-d-announce

On Friday, 6 January 2023 at 12:52:43 UTC, Hipreme wrote:
Hello people. I have tried working again with adam's wasm 
minimal runtime, and yesterday I was able to make a great 
progress on it.




Awesome! To think that custom druntime can get you out of 
platform situations is great risk reduction.