14.09.2021 21:46, IGotD- пишет:
> On Tuesday, 14 September 2021 at 18:03:32 UTC, Kenneth Dallmann wrote:
>>
>> D has a full set of OOP features, but it may not play as well with pointers and
>> bare metal code as Rust.
> 
> Yes and no. In betterC classes are disabled as well as TypeInfo. In betterC you have to use structs and structs do not provide full OOP features, only composition (there are hacks around this I've seen). For many systems structs are enough but sometimes you want full classes with inheritance and virtual methods. I would like that betterC could allow classes as well as TypeInfo. For very small embedded system TypeInfo might just eat up important space but for medium or large ones, TypeInfo can actually help.
> 
> In the ideal world I would like that the OOP features of D becomes more bare metal friendly. This also leads into the memory management discussion, but I'll leave that out in this thread.
> 
> I've also read the Rust is disliked for small embedded systems because of the restrictive memory model. People seem to flee to other programming languages for like Zig if it is not C/C++. I think D can position itself better here if we can get our act together when it comes to the memory model.

I don't test it but can't you use extern(C++) classes in DasBetterC mode?

On Tuesday, 14 September 2021 at 18:46:09 UTC, IGotD- wrote:
> In betterC classes are disabled as well as TypeInfo.

You can actually still use extern(C++) classes even with -betterC.

Strangely though interfaces don't work there, but probably just an oversight bug (betterC is all about arbitrary limitations...).


But -betterC sucks anyway. Just use a minimal custom runtime and get exactly what you want!

http://dpldocs.info/this-week-in-d/Blog.Posted_2020_07_27.html#zero-runtime-classes

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.

On 9/14/2021 11:03 AM, Kenneth Dallmann wrote:
> There might be some potholes in the design of D.  I think if I were to design
> something like D I would follow Rust's example for memory management, and then
> add in GC as an optional feature.

GC already is an optional feature in D.

On Wednesday, 15 September 2021 at 10:00:39 UTC, Walter Bright wrote:
>
> GC already is an optional feature in D.

It depends what you mean by that, arrays and about all other data structures rely on GC. Also entire Phobos require GC.

D without any libraries does not rely on GC but then you have removed many useful features of the language. The situation is similar with C++ but there the library only depends on malloc/free without any extra memory penalty and tracing penalty.

On 15/09/2021 10:28 PM, IGotD- wrote:
> On Wednesday, 15 September 2021 at 10:00:39 UTC, Walter Bright wrote:
>>
>> GC already is an optional feature in D.
> 
> It depends what you mean by that, arrays and about all other data structures rely on GC. Also entire Phobos require GC.

False. std.traits works just fine ;)

std.format could work if it wasn't for exceptions!

> D without any libraries does not rely on GC but then you have removed many useful features of the language. The situation is similar with C++ but there the library only depends on malloc/free without any extra memory penalty and tracing penalty.

There really are only 3 features that you end up missing in -betterC, aside from the GC.

Exceptions, classes, TLS.

Classes are slowly coming along, but they are being resolved.
https://issues.dlang.org/show_bug.cgi?id=21416 is as far as I'm aware one of the few bugs associated with it.

TLS is out of the question as far as I'm aware.

Exceptions, using stack unwinding do need a runtime, so they are out, but I *really* want to see that resolved. I'd love to see an alternative to heap allocated stack unwinding exceptions in D.

On Wednesday, 15 September 2021 at 10:35:50 UTC, rikki cattermole wrote:
>
> On 15/09/2021 10:28 PM, IGotD- wrote:
>> [...]
>
> False. std.traits works just fine ;)
>
> std.format could work if it wasn't for exceptions!
>
>> [...]
>
> There really are only 3 features that you end up missing in -betterC, aside from the GC.
>
> Exceptions, classes, TLS.
>
> Classes are slowly coming along, but they are being resolved.
> https://issues.dlang.org/show_bug.cgi?id=21416 is as far as I'm aware one of the few bugs associated with it.
>
> TLS is out of the question as far as I'm aware.
>
> Exceptions, using stack unwinding do need a runtime, so they are out, but I *really* want to see that resolved. I'd love to see an alternative to heap allocated stack unwinding exceptions in D.

Why is TLS out of question, when it is a standard C11 feature?

On 15/09/2021 11:43 PM, Paulo Pinto wrote:
> Why is TLS out of question, when it is a standard C11 feature?

-betterC can be used without a libc.

It is also a different implementation compiler hook wise to regular D.

The problem is, regardless of who implements it, it still needs a runtime.