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
