June 09, 2021

On Wednesday, 9 June 2021 at 15:25:59 UTC, lili wrote:

>

No, But it's on the way, lack useful library, lack ecosystem.

Is this really true tho? What are you missing? 🤔

September 13, 2021

On Saturday, 5 June 2021 at 23:33:59 UTC, The Reaper wrote:

>

It seems like it, after a year or so hiatus there is very little activity. Seems like D is gone as I predicted it would be because of the lack of passion to push it forward and turn it in to a competitive modern project. Boomers killed D ;/

C has been around for a long time and is the de facto language of almost everything. To my understanding, Rust and D are the only two languages that can compete.

D is certainly not dead and it's lack of popularity doesn't mean it is less valuable either.
I can explain why:

D is fluent with C, so you can access the libraries made in C.

D has a full range of OOP features that is unparalleled in the systems level paradigm. The only competitor is C++, and that language has become syntatically displeasing.

I can highlight some strengths and weaknesses:

D has a full range of OOP features; clean syntax; garbage collection, like some of the most popular languages now, like Java and Python; full access to hardware and assembly friendly; and OOP in D can be implemented in a very precise way, thanks to structs and classes.

On the flip side: D's garbage collection adds runtime overhead.

For bit by bit performance I would probably choose Rust over D, however unless you're programming very small embedded devices the performance differences are likely trivial.

September 13, 2021

On Monday, 13 September 2021 at 18:31:59 UTC, Kenneth Dallmann wrote:

>

C has been around for a long time and is the de facto language of almost everything. To my understanding, Rust and D are the only two languages that can compete.

It's a little bit more than that. Contenders to C are

C++
D
Rust
Nim
Zig

My criteria is that the languages work on bare metal with minimum library support. Some made Go work with small embedded systems but still requires a runtime so I don't consider Go to be a contender. D barely qualifies for this category as there are so many library functions that require GC. If betterC didn't exist I would have excluded D.

September 14, 2021

On Monday, 13 September 2021 at 20:04:01 UTC, IGotD- wrote:

>

On Monday, 13 September 2021 at 18:31:59 UTC, Kenneth Dallmann wrote:

>

C has been around for a long time and is the de facto language of almost everything. To my understanding, Rust and D are the only two languages that can compete.

It's a little bit more than that. Contenders to C are

C++
D
Rust
Nim
Zig

My criteria is that the languages work on bare metal with minimum library support. Some made Go work with small embedded systems but still requires a runtime so I don't consider Go to be a contender. D barely qualifies for this category as there are so many library functions that require GC. If betterC didn't exist I would have excluded D.

You might not consider it a contender, but business that matter do,

https://www.f-secure.com/en/consulting/foundry/usb-armory

https://gvisor.dev

https://cloud.google.com/kubernetes-engine/docs/concepts/sandbox-pods

https://blog.arduino.cc/2019/08/23/tinygo-on-arduino

September 14, 2021

On Tuesday, 14 September 2021 at 06:12:37 UTC, Paulo Pinto wrote:

>

You might not consider it a contender, but business that matter do,

https://www.f-secure.com/en/consulting/foundry/usb-armory

https://gvisor.dev

https://cloud.google.com/kubernetes-engine/docs/concepts/sandbox-pods

https://blog.arduino.cc/2019/08/23/tinygo-on-arduino

Can TinyGo totally drop the runtime and manage memory malloc/free style? If so, that makes it a true systems language IMO. And if it can, how much of the language is still usable? C# can handle raw pointers and memory and thus is in principle a systems language if compiled to binary code, but it's a bad one because it's so crippled in that domain (I mean standard C#. I think you could tell me about variants that are better.).

Whether it can run on a low-power low-memory platform does not determine whether the language is a systems language, though that ability is still cool and useful. Home computers of the 80s ran BASIC but weren't powerful enough for C++ exception handling IIRC Walters stories correctly. Still it's C++ and not BASIC that is considered the systems language.

September 14, 2021

On Tuesday, 14 September 2021 at 09:17:40 UTC, Dukc wrote:

>

On Tuesday, 14 September 2021 at 06:12:37 UTC, Paulo Pinto wrote:

>

[...]

Can TinyGo totally drop the runtime and manage memory malloc/free style? If so, that makes it a true systems language IMO. And if it can, how much of the language is still usable? C# can handle raw pointers and memory and thus is in principle a systems language if compiled to binary code, but it's a bad one because it's so crippled in that domain (I mean standard C#. I think you could tell me about variants that are better.).

Whether it can run on a low-power low-memory platform does not determine whether the language is a systems language, though that ability is still cool and useful. Home computers of the 80s ran BASIC but weren't powerful enough for C++ exception handling IIRC Walters stories correctly. Still it's C++ and not BASIC that is considered the systems language.

A systems programming language is one that can be used to write the full stack OS in it, period.

As for being able to drop the runtime to be considered a systems programming language, I guess that rules out Ada and C++ then.

September 14, 2021
On Tuesday, 14 September 2021 at 09:21:07 UTC, Paulo Pinto wrote:
>
> A systems programming language is one that can be used to write the full stack OS in it, period.

I guess there are as many definitions as there are programmers for "systems programming language". But regardless of the definition, I'm interested: can you write a Go program without it's GC, and how much of the language is usable without it, if?

>
> As for being able to drop the runtime to be considered a systems programming language, I guess that rules out Ada and C++ then.

I'm pretty sure you can drop the extra parts of C++ runtime with the linkers unused symbol stripper, if nothing else. Granted, that only works if you don't use the parts of C++ runtime you want to drop but it is still reasonable to use it that way.
September 14, 2021
On Tuesday, 14 September 2021 at 09:37:38 UTC, Dukc wrote:
> On Tuesday, 14 September 2021 at 09:21:07 UTC, Paulo Pinto wrote:
>>
>> A systems programming language is one that can be used to write the full stack OS in it, period.
>
> I guess there are as many definitions as there are programmers for "systems programming language". But regardless of the definition, I'm interested: can you write a Go program without it's GC, and how much of the language is usable without it, if?
>

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.

So apparently Go not fitting your definition of systems programming language doesn't hinder it having more success in the market on that regard.

>>
>> As for being able to drop the runtime to be considered a systems programming language, I guess that rules out Ada and C++ then.
>
> I'm pretty sure you can drop the extra parts of C++ runtime with the linkers unused symbol stripper, if nothing else. Granted, that only works if you don't use the parts of C++ runtime you want to drop but it is still reasonable to use it that way.

Indeed, by making use of language extensions and compiler specific implementations not defined by ISO C++.

And I am not defending arguing Go only.

PTC Java, Aicas Java, microEJ, Meadow .NET are also part of what I would consider.

Including D, with a minimal runtime instead of stuff like DasBetterC.


September 14, 2021
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?


> So apparently Go not fitting your definition of systems programming language doesn't hinder it having more success in the market on that regard.

Not pushing my definition of systems programming to the dictionary. In hindsight it was stupid for me to even bring it up, since I don't know it's formal definition if there even is one.


>
> And I am not defending arguing Go only.
>
> PTC Java, Aicas Java, microEJ, Meadow .NET are also part of what I would consider.
>
> Including D, with a minimal runtime instead of stuff like DasBetterC.

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.
September 14, 2021
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:
>> [...]
>
> 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?
>
> [...]

Imo, D would/could be the perfect fit for embedded