Anon (no.delete@this.spam.com) on July 20, 2021 10:53 am wrote:
> Michael S (already5chosen.delete@this.yahoo.com) on July 20, 2021 10:14 am wrote:
> > Anon (no.delete@this.spam.com) on July 20, 2021 6:24 am wrote:
> > > gallier2 (gallier2.delete@this.gmx.de) on July 20, 2021 4:57 am wrote:
> > > > Looks like a good candidate for D.
> > > > https://tour.dlang.org/
> > >
> > > I like D, but this language don't have all the support for
> > > me to try it, the big boys usually prefer to create
> > > their own language instead of adopting one so we ended with many similar languages but incompatible.
> > >
> >
> > Isn't D GC-based, so unsuitable for kernel?
> >
>
> Yes, but GC is not strictly required, and there is one "interesting" build option:
> https://dlang.org/spec/betterc.html
>
> I don't know how much pain enabling this option causes.
>
From the language perspective DasBetterC make you lose concatenation operator ~, some cases of delegates and inbuilt associative arrays. Some part of the standard library Phobos also will not work without the GC. This said, CTFE (compile time function execution), one of the highlight feature of D, still can make use of these features. As DasBetterC is generally intended for "embedded" work where the resulting binary is meant to be very static, compile time execution is important.

https://dlang.org/blog/the-d-and-c-series/

As for D work for Linux Kernel, there was a SAoC (Symmetry Autumn of Code) project in 2019 that did interface automatically D code into the Linux Kernel. Afaict the project ended successfully in allowing to write kernel drivers in D.

PS: btw there is currently a new feature that will be presented soon(ish) of the D compiler capable of compiling C code directly. Just for info.