On Saturday, 10 April 2021 at 18:57:39 UTC, Max Haughton wrote:

The only premise OP has offered is Rust but simpler(TM). I'm not saying D should be unsafe, but coming in with the basis of Rust but simpler(TM) and no explanation what that means or how to achieve it, then yeah, it's an open ended moot point. Especially after saying no one wants to use D with GC (so I assume D's metaprogramming, UCFS, contract programming, etc means nothing) because Go exists and then says D should be like Rust, when Rust exists.

D is a community project. If you want it to change, write a DIP, commit some code or donate. I want D to be better in the embedded world, so I've been writing a suitable runtime and I've donated to the foundation.

On Saturday, 10 April 2021 at 20:04:03 UTC, Independent wrote:

I'm kind of torn on this.

I'm not sure that anyone really has a long term vision of what D will be. It's becoming quite a different language from even 10 years ago. It is quite affirming to hear someone say "this is what X will be in 5 years".

At the same time, D's evolution does feel a bit more organic, as contributors commit things they feel is beneficial for the language in a decentralised manner.

On Saturday, 10 April 2021 at 23:25:40 UTC, Dylan Graham wrote:

Here are some ideas,

Meadow Platform, a µRTOS and full .NET Standard compatible runtime.

https://www.wildernesslabs.co/developers

Had it been in D, there would be no need for the µRTOS, everything would be in D.

microEJ, a µRTOS and Java based runtime.

https://www.microej.com/

Also a nice candidate for D.

Unity, now the must go engine for anyone that wants to do game dev, AR and VR without having to deal with C++ as much as possible.

Had it been in D, HPC# and Burst compiler would have been D with @nogc.

F-Secure decided Go is good enough for bare metal coding, so USB Armory with TamaGo unikernel was born, yet another use case where D would have shinned.

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

Discussing if D would be better with or without GC is pointless, rather improving the already existing language, so that companies like the examples above can look at D and place it on their candidate list for final decision how to build their products.

On Sunday, 11 April 2021 at 09:29:35 UTC, Paulo Pinto wrote:

I think you misunderstand my position. The comment you replied to was me discussing D's leadership/outlook style.

In my comment above that, I did mention exactly what you are doing. LWDR is my attempt to make full D accessible in the embedded world. I am trying to improve D in a sector that I personally prioritise.

On Sunday, 11 April 2021 at 09:47:15 UTC, Dylan Graham wrote:

I was kind of agreeing with you, the goal needs to be to improve existing features, trying to sell it to the GC haters crowd is worthless effort, they will just come up with the next reason why D isn't suitable for them.

On Sunday, 11 April 2021 at 10:10:02 UTC, Paulo Pinto wrote:

My apologies, I misinterpreted what you were saying. I agree. D has made many efforts to reduce it's GC dependency and there are packages to help bridge the gaps the language can't. Alas, there is still a lot of die-hard anti-GC folk.

Honestly, I kinda of like the simplicity of D's GC. I know why it's going to run, when it's going to run and what it will do. In tight situations where I don't want the GC, it's super easy to avoid. D currently has a tremendous amount of flexibility, I can develop fast where I want and blazing performance where I want. I feel like D's flexibility is criminally undervalued.

On Sunday, 11 April 2021 at 09:29:35 UTC, Paulo Pinto wrote:

+1

On Sunday, 11 April 2021 at 09:47:15 UTC, Dylan Graham wrote:

I really appreciate the work you've doing for getting D to embedded. It's one of the last pieces for us/me to adopt D 100%