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?
