On Thursday, 4 January 2018 at 10:18:29 UTC, Dan Partelly wrote:

> Rust has a OS being written right now. Does D has ? Anyone ever wanted to use D to write a OS kernel

https://github.com/xomboverlord/xomb
https://github.com/PowerNex/PowerNex
https://github.com/JinShil/stm32f42_discovery_demo

But they don't seem to compare to https://github.com/redox-os/redox or https://github.com/helena-project/tock

My interest in D is primarily to be able to use it for ARM Cortex-M microcontrollers.  Unfortunately, Rust is kicking D's butt in that domain (https://japaric.github.io/discovery/).  But I just don't enjoy programming in Rust like I do in D.  So, I'm trying to see what I can do to reduce the coupling between the compiler and the runtime so I can use D in a more pay-as-you-go fashion.  One of my first PRs in that regard was pulled recently (https://github.com/dlang/dmd/pull/7395) and I have a few more ideas along those lines.  But, I still have a lot to learn.

Mike

On Thursday, 4 January 2018 at 10:18:29 UTC, Dan Partelly wrote:
>
> Rust has a OS being written right now. Does D has ? Anyone ever wanted to use D to write a OS kernel, I doubt it.

https://github.com/PowerNex/PowerNex
https://github.com/Rikarin/Trinix


> Id rather use a nice language as D to write new software, not to port old **working**   tools which are only maintained and not developed to it. I see no sense for that.

But others do ;-)

On Thursday, 4 January 2018 at 10:49:49 UTC, Dgame wrote:
> On Thursday, 4 January 2018 at 10:40:33 UTC, Ola Fosheim Grøstad wrote:
>> However, Rust won't fare well in a head-to-head comparison either, because of the issues with back-pointers.
>
> Could you explain this?

You often want back-pointers for performance reasons, but Rust default pointer model isn't as accepting to cycles. So you either have to change your design or loose the benefits that the compiler provides, at which point C++ is more convenient, but it depends on what you try to do.

On Thursday, 4 January 2018 at 10:18:29 UTC, Dan Partelly wrote:

> Yes, disabling GC might have been a feature early on. But not early on enough to not have core language features depending on it, and not early enough to have a std not depending on it. Modifying the std to be more compatible with this scenario is indeed happening, but as you say it is a process which started years ago, and its still dragging on, and no clear docs with what works and what not.

I fundamentally disagree with the idea that core features shouldn't depend on the GC. I love that they do. As for Phobos, I also don't expect it to be completely GC-free. If there are parts of it that can be but aren't, then perhaps a PR?

>
> Rust has a OS being written right now. Does D has ? Anyone ever wanted to use D to write a OS kernel, I doubt it.

There have been at least three kernels in D that I know of, the most recent being PowerNex. However, I'm unaware of any that are non-hobby projects.

>Is anyone
> seriously thinking today to port their *working* and maintained C code bases to D, possibly introducing new bugs in the process ? (yes some people like Walter did, Im aware of this. But I doubt this will have any serious adoption)

I can't answer for Walter, but my understanding is yes, there are. He and Andrei have communication with interests outside of these forums.

The whole point of -betterC is to *avoid* the introduction of new bugs. It allows you to port your C code directly to D with very minimal changes. You can convert a function to D, compile the object, link the program, and make sure it works as expected. It allows you to continue to distribute/use your program before it is fully ported and to verify that it works as expected. Walter's use of it is a real-world use case that shows how useful it is.

>
> Id rather use a nice language as D to write new software, not to port old **working**   tools which are only maintained and not developed to it. I see no sense for that.

So, how does the existence of -betterC stop you from writing new software? I'm using D without -betterC just fine.

On Thursday, 4 January 2018 at 11:04:51 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 4 January 2018 at 10:49:49 UTC, Dgame wrote:
>> On Thursday, 4 January 2018 at 10:40:33 UTC, Ola Fosheim Grøstad wrote:
>>> However, Rust won't fare well in a head-to-head comparison either, because of the issues with back-pointers.
>>
>> Could you explain this?
>
> You often want back-pointers for performance reasons, but Rust default pointer model isn't as accepting to cycles. So you either have to change your design or loose the benefits that the compiler provides, at which point C++ is more convenient, but it depends on what you try to do.

As far as I remember you can use pointers as you normally do if you use them in unsafe blocks. Not that I ever tried.