Is D Dead?

[Paulo Pnito]

On Tuesday, 14 September 2021 at 12:52:00 UTC, Dukc wrote:
> On Tuesday, 14 September 2021 at 11:36:30 UTC, Paulo Pinto 
> wrote:
>>
>> Why should I constrain myself, GC has a place in systems 
>> programming as proven by stuff being shipped in production, 
>> more so than what D has achieved thus far.
>
> And I didn't say "GC does not belong to systems programming". I 
> asked whether Go can do without GC if someone wants to manage 
> memory 100% manually anyway?

Well, Go is bootstraped and the GC is written in Go itself.

https://github.com/golang/go/blob/master/src/runtime/malloc.go

In any case, just like C and C++ have subsets for embedded use, 
in TamaGo you can for example do DMA in plain Go code.

https://github.com/f-secure-foundry/tamago/blob/master/dma/alloc.go

https://github.com/f-secure-foundry/tamago/blob/master/dma/dma.go

https://github.com/f-secure-foundry/tamago/blob/master/soc/bcm2835/dma.go

Naturally there is some Assembly, just like even C needs Assembly 
for the features not available in ISO C.

> ...
>
> Hmm, DasBetterC and C have an underlying runtime too. I think 
> you're saying that such a minimal runtime C has is an outdated 
> approach, that a high-language should have a heavier runtime 
> than that even when doing systems programming? And the real-low 
> level stuff where you just can't use the GC but could use 
> C++/Rust/DasBetterC (like some device drivers and the 
> implementation of GC) are so few that it's just better to use C 
> or assembly there? That it's not worthwhile for higher-level 
> languages to target that niche?
>
> I'm actually fairly neutral on that argument when talking about 
> languages in general. I don't know about bare-metal programming 
> enough to be sure. But D is pretty much committed to support 
> the said niche, so I don't think reversing that decision is a 
> good idea even if the niche isn't that important in general.

Coming back to D, basically my point is that GC is part of the 
productivity equation, even in systems programming.

Naturally there are scenarios where any kind of memory allocation 
is a no-go, those where SPARK, MISRA-C and formal methods are the 
only options.

However there are plenty of other kinds of deployment scenarios, 
where those strict requirements don't play a role and as such, D 
can be a good choice with the runtime for the ride.

If you prefer one of those typical car analogies, classical 
manual memory management is like driving stick with fossil fuel, 
while using D with all its features, is driving a Porsche Taycan.

Surely there are plenty of cases where the old technology still 
wins out, yet the trend is clear.