What is the state of Microcontroller support in d?

[Dan Walmsley via Digitalmars-d]

On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote:
> On Monday, 19 June 2017 at 20:01:01 UTC, Dan Walmsley wrote:
>
>> Hi you still around, I'm starting to investigate these issues 
>> and see if I can start using D in some of my embedded projects 
>> at my company. I've got stuck at the hurdle of trying to use 
>> minilibd with Ldc compiler, did you make progress since this 
>> post?,
>
> IMO microcontroller support in D is only slightly better than 
> non-existent.  I tried about 2 or 3 years ago to move the ball 
> forward on it, but just ran into way too many obstacles.  The 
> nail in the coffin for me was 
> https://issues.dlang.org/show_bug.cgi?id=14758.
>
> To enumerate some of the problems (I don't have the energy for 
> an exhaustive list, so these are just off the top of my head at 
> the moment)
>
> 1.  Compiler-runtime coupling.  The compiler expects too much 
> of the runtime to exist even when what it requires has no hope 
> of ever being executed in the resulting binary.  So, it forces 
> us to implement silly hacks and stubs just to get a build.
>
> 2.  The compiler adds things that aren't even needed in the 
> resulting binary, and does so in a way that prevents 
> --gc-sections and LTO from removing them.  For some of my code, 
> the binary was so large it wouldn't even fit on the 
> microcontroller's flash memory.
>
> 3.  Many of the veterans in the D community support the current 
> dependency the runtime has on C standard library bindings, 
> stating that they are required (which is not true).  
> Furthermore, they want to make the problem worse by adding C++ 
> standard library bindings as well.  I submitted  pull request 
> to begin moving these bindings to Deimos, and make the 
> dependencies private for individual platforms' ports, but only 
> encountered resistance and misunderstanding.
>
> 4.  The D gatekeepers have become very averse to anything that 
> would cause too much disruption, making me believe that the 
> fundamental changes that are needed to make microcontroller 
> programming in D a reality will never be accepted.
>
> 5.  Too many pull requests sit in "purgatory" for way too long 
> without any progress.  I believe that trying to move my changes 
> forward would be an uphill battle, and ultimately not worth the 
> frustration.
>
> 6.  Rust has "minimal runtime" as one of the pillars of its 
> language design philosophy.  You can truly pay-as-you go while 
> you build your system.  This is how it should be, and unless 
> you're looking for a fight, you'll probably be better off 
> there:  http://blog.japaric.io/quickstart/.  That's where I'm 
> allocating my resources these days.
>
> Mike

How about creating a fork and calling it "SystemD or EmbeddedD" 
just 1 compiler (LDC probably), do you think its realistic idea?

I was so hopeful for D when I saw how nice the syntax is, I saw 
rust and I didn't get the same feeling, not that I wont give it a 
chance, I just feel as you know embedded systems is dominated by 
C and C++ and D seems closer to those than Rust.

To be fair I was impressed with the -betterC flag and that 
actually looks nice I you just want a C replacement but no 
classes, etc.

I have not been able to get even a minimal project to compile 
when a class is introduced

`Error: Missing class declaration: TypeInfo_AssociativeArray`

Will take a look at rust, but would be keen to know if you could 
be motivated by the SystemD / EmbeddedD idea?