www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is modern D ready for "embedded first" paradigm?

reply Dmitry Ponyatov <dponyatov gmail.com> writes:
Reading some posts about the D language here and there I found 
some opinion that D is not popular because it still did not find 
its kill features set and application domain.

What do you think about promoting D lang as a main development 
language for embedded, IoT, and real-time multimedia & automation 
applications?

Is D ready in its current state (including runtime, stdlib and 
side libraries) to follow the cross-compile way as a main method 
of its usage? (GDC/LDC)

Many decades the classical C and some limited set of C++ plays in 
this area, but nowadays embedded (Arduino, Raspberry, etc) raised 
its usage among hobbits and not so qualified and non-professional 
programmers and users. Maybe this directon can push the D 
language in its evolution and popularity, as people now needs 
some multiplatform optimizing compiler for rich and handy 
language but not so complex as classical C, or mbed/Arduino-like 
C++ dialects?
Oct 09 2023
next sibling parent Dmitry Ponyatov <dponyatov gmail.com> writes:
Also, under the more wide "cross-compile first" paradigm I mean 
that all D toolchains should be sharpened for building and 
testing projects transparently for multimple (and any if 
possible) hw/OS targets, at least for 
Windows[wine,mingw32/64]/Linux/MacOS running build under the same 
big-three hosts.
Oct 09 2023
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 10 October 2023 at 06:39:14 UTC, Dmitry Ponyatov 
wrote:

 Reading some posts about the D language here and there I found 
 some opinion that D is not popular because it still did not 
 find its kill features set and application domain.

 What do you think about promoting D lang as a main development 
 language for embedded, IoT, and real-time multimedia & 
 automation applications?

 Is D ready in its current state (including runtime, stdlib and 
 side libraries) to follow the cross-compile way as a main 
 method of its usage? (GDC/LDC)

 Many decades the classical C and some limited set of C++ plays 
 in this area, but nowadays embedded (Arduino, Raspberry, etc) 
 raised its usage among hobbits and not so qualified and 
 non-professional programmers and users. Maybe this directon can 
 push the D language in its evolution and popularity, as people 
 now needs some multiplatform optimizing compiler for rich and 
 handy language but not so complex as classical C, or 
 mbed/Arduino-like C++ dialects?



support in some of their SDKs.

Yes it would be nice to make D part of that list, however just 
like in other domains there is at least a decade of tooling to 
catch up with.
Oct 10 2023
parent reply Dmitry Ponyatov <dponyatov gmail.com> writes:



on 20K RAM microcontroller? 8)

or on a Raspberry-like board controls some CNC machine or 3D 
printer in hard realtime?


 Rust are already there,


maybe, but in my experience Rust totally unacceptable not only by 
newbies in home&hobby control, but even with people with more 
then twenty years of coding -- I mean in original post, that D 
can catch this market segment even comparing to C++
Oct 10 2023
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 11 October 2023 at 00:45:40 UTC, Dmitry Ponyatov 
wrote:




 on 20K RAM microcontroller? 8)

 or on a Raspberry-like board controls some CNC machine or 3D 
 printer in hard realtime?


 Rust are already there,


 maybe, but in my experience Rust totally unacceptable not only 
 by newbies in home&hobby control, but even with people with 
 more then twenty years of coding -- I mean in original post, 
 that D can catch this market segment even comparing to C++


Imo D is ready. BetterC exists. ImportC exists. There's nothing 
stopping us.
Oct 10 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 11 October 2023 at 05:38:43 UTC, Imperatorn wrote:

 On Wednesday, 11 October 2023 at 00:45:40 UTC, Dmitry Ponyatov 
 wrote:




 on 20K RAM microcontroller? 8)

 or on a Raspberry-like board controls some CNC machine or 3D 
 printer in hard realtime?


 Rust are already there,


 maybe, but in my experience Rust totally unacceptable not only 
 by newbies in home&hobby control, but even with people with 
 more then twenty years of coding -- I mean in original post, 
 that D can catch this market segment even comparing to C++


 Imo D is ready. BetterC exists. ImportC exists. There's nothing 
 stopping us.


Also, this exists:
https://forum.dlang.org/thread/giigcnoyxfoxxaevjmxy forum.dlang.org

And this:
https://wiki.dlang.org/Programming_in_D_tutorial_on_Embedded_Linux_ARM_devices

And this:
https://wiki.dlang.org/D_on_AVR

And this:
https://wiki.dlang.org/D_on_esp32/esp8266(llvm-xtensa%2Bldc)_and_how_to_get_started

And this is a good resource:
https://github.com/WebFreak001/avrd

Some extra reading:
https://github.com/JinShil/stm32f42_discovery_demo
Oct 10 2023
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 11 October 2023 at 00:45:40 UTC, Dmitry Ponyatov 
wrote:




 on 20K RAM microcontroller? 8)


Only on your dreams does D fit into a 20K controller, when even 
ISO C doesn't.

Yes, maybe with betterC there is a subset that one can make into 
it, but that isn't D, just like C dialects that fit into such 
controllers, full with language extensions aren't ISO C proper.

And yes, if dialects are allowed, there are also microcontroller 
versions.


 or on a Raspberry-like board controls some CNC machine or 3D 
 printer in hard realtime?


 Rust are already there,


 maybe, but in my experience Rust totally unacceptable not only 
 by newbies in home&hobby control, but even with people with 
 more then twenty years of coding -- I mean in original post, 
 that D can catch this market segment even comparing to C++


Since a market reality check seems to be required, instead of me 
just telling they exist out there.

Java:

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/wp/products-services/jamaicavm/

https://www.microej.com/product/sdk/

https://developer.itron.com/

Go:

https://www.withsecure.com/en/solutions/innovative-security-hardware/usb-armory

https://tinygo.org/



https://www.wildernesslabs.co/

https://www.nanoframework.net/

Rust:

https://ferrous-systems.com/blog/announce-esp-training/

https://techcommunity.microsoft.com/t5/internet-of-things-blog/modernizing-embedded-development-on-azure-sphere-with-rust/ba-p/3699383

https://www.adacore.com/gnatpro-rust

https://www.windriver.com/products/vxworks/datasheet

Ada:

https://www.adacore.com/

https://www.ghs.com/products/ada_optimizing_compilers.html

https://www.ptc.com/en/products/developer-tools/apexada

https://www.ddci.com/products_score/

http://www.irvine.com/tech.html

http://www.ocsystems.com/w/index.php/OCS:PowerAda

http://www.rrsoftware.com/html/prodinf/janus95/j-ada95.htm

A not exhaustive list of production quality toolchains, some of 
them more than a decade in production and existing customer base.
Oct 11 2023
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 10 October 2023 at 06:39:14 UTC, Dmitry Ponyatov 
wrote:

 Reading some posts about the D language here and there I found 
 some opinion that D is not popular because it still did not 
 find its kill features set and application domain.

 What do you think about promoting D lang as a main development 
 language for embedded, IoT, and real-time multimedia & 
 automation applications?

 Is D ready in its current state (including runtime, stdlib and 
 side libraries) to follow the cross-compile way as a main 
 method of its usage? (GDC/LDC)


If we're talking about a a bare-metal real-time application in a 
microcontroller, honestly no. D can do this sort of thing but 
it's not currently it's strong area. You're almost without 
library support in those platforms. Phobos does work with 
`-betterC` (or generally without a full-featured DRuntime) but it 
means continuously dealing with all sorts of incompatibilities 
and corner cases.

However, if we're talking about something like Raspberry Pi 
embedded applications, I could see D being a much better option - 
I haven't tried myself though so listen to anyone who has.
Oct 12 2023
next sibling parent Dukc <ajieskola gmail.com> writes:
On Thursday, 12 October 2023 at 07:06:15 UTC, Dukc wrote:

 If we're talking about a a bare-metal real-time application in 
 a microcontroller, honestly no. D can do this sort of thing but 
 it's not currently it's strong area. You're almost without 
 library support in those platforms. Phobos does work with 
 `-betterC` (or generally without a full-featured DRuntime) but 
 it means continuously dealing with all sorts of 
 incompatibilities and corner cases.


That said, D is still a better choice than C in my opinion. But 
if the platform in question has a good standard library support
Oct 12 2023
prev sibling parent reply Denis Feklushkin <feklushkin.denis gmail.com> writes:
On Thursday, 12 October 2023 at 07:06:15 UTC, Dukc wrote:


 If we're talking about a a bare-metal real-time application in 
 a microcontroller, honestly no. D can do this sort of thing but 
 it's not currently it's strong area. You're almost without 
 library support in those platforms. Phobos does work with 
 `-betterC` (or generally without a full-featured DRuntime) but 
 it means continuously dealing with all sorts of 
 incompatibilities and corner cases.


First (and most importand) step to achieve support of bare-metal 
platforms is druntime implementation.

Before, I successfully implemented druntime hacks for checking 
possibility of work D (not betterC!) on STM32 platform ("Hello, 
world!" and druntime unittests are passed): 
https://github.com/denizzzka/d_c_arm_test

Unfortunately, without changes to the existing druntime code 
organization it seems to impossible to support different 
non-mainstream architectures. And, at first, this applies to 
embedded ones.

Therefore, please support (or give constructive criticism 
feedback) this initiative:
https://forum.dlang.org/post/jdfwovvqdcusjphehwzx forum.dlang.org 
- this link explains everything in more detail
https://github.com/dlang/dmd/pull/15822 - here is PR with 
additional info
Dec 08 2023
next sibling parent Denis Feklushkin <feklushkin.denis gmail.com> writes:
On Friday, 8 December 2023 at 19:01:16 UTC, Denis Feklushkin 
wrote:


 possibility of work D (not betterC!) on STM32 platform ("Hello, 
 world!" and druntime unittests are passed): 
 https://github.com/denizzzka/d_c_arm_test


Forgot to add lovely "Hello, World!" video:
https://www.youtube.com/watch?v=PE6pMUA0vNQ

Nostalgia! Oh, how great it was! :-)
Dec 08 2023
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Friday, 8 December 2023 at 19:01:16 UTC, Denis Feklushkin 
wrote:

 On Thursday, 12 October 2023 at 07:06:15 UTC, Dukc wrote:


 If we're talking about a a bare-metal real-time application in 
 a microcontroller, honestly no. D can do this sort of thing 
 but it's not currently it's strong area. You're almost without 
 library support in those platforms. Phobos does work with 
 `-betterC` (or generally without a full-featured DRuntime) but 
 it means continuously dealing with all sorts of 
 incompatibilities and corner cases.


 First (and most importand) step to achieve support of 
 bare-metal platforms is druntime implementation.


It doesn't necessarily need to be full support and probably won't 
be for a simple and small microchip project.


 Before, I successfully implemented druntime hacks for checking 
 possibility of work D (not betterC!) on STM32 platform ("Hello, 
 world!" and druntime unittests are passed): 
 https://github.com/denizzzka/d_c_arm_test

 Unfortunately, without changes to the existing druntime code 
 organization it seems to impossible to support different 
 non-mainstream architectures. And, at first, this applies to 
 embedded ones.


Reorganisation of the sort you and Iain are pushing for certainly 
could help. However I think even more important is support for 
only a partially implemented DRuntime - if you don't use a 
runtime feature, D shouldn't require it being implemented. With 
the mainstream DRuntime this currently work badly because of the 
`version (...) else static assert(0, "unsupported platform")` 
paradigm, meaning one has to manually stub all of those. There 
should be a way to do this without manual work.

Dylan Grahams Lightweight DRuntime seems perfect for these use 
cases for me but haven't tried so far.


 Therefore, please support (or give constructive criticism 
 feedback) this initiative:
 https://forum.dlang.org/post/jdfwovvqdcusjphehwzx forum.dlang.org - this link
explains everything in more detail
 https://github.com/dlang/dmd/pull/15822 - here is PR with 
 additional info


Not promising but I'll try to remember next time I'm hacking my 
own projects.
Dec 10 2023
parent reply Denis Feklushkin <feklushkin.denis gmail.com> writes:
On Monday, 11 December 2023 at 07:59:43 UTC, Dukc wrote:

dmd/druntime/README.md:
```
Different compilers will likely have their own versions of 
DRuntime.
```

In my opinion, the idea of different DRuntimes for a different 
tasks should be considered as failed in 2023. It hasn't stood the 
test of time
Dec 11 2023
parent IGotD- <nise nise.com> writes:
On Monday, 11 December 2023 at 09:26:48 UTC, Denis Feklushkin 
wrote:

 dmd/druntime/README.md:
 ```
 Different compilers will likely have their own versions of 
 DRuntime.
 ```

 In my opinion, the idea of different DRuntimes for a different 
 tasks should be considered as failed in 2023. It hasn't stood 
 the test of time


They don't really have their own druntime but rather have their 
own adapted fork of the dmd druntime for compiler specific things 
like intrinsics. Still it is the same druntime with just a few 
modifications.
Dec 11 2023
prev sibling parent reply IGotD- <nise nise.com> writes:
On Tuesday, 10 October 2023 at 06:39:14 UTC, Dmitry Ponyatov 
wrote:

 Reading some posts about the D language here and there I found 
 some opinion that D is not popular because it still did not 
 find its kill features set and application domain.

 What do you think about promoting D lang as a main development 
 language for embedded, IoT, and real-time multimedia & 
 automation applications?

 Is D ready in its current state (including runtime, stdlib and 
 side libraries) to follow the cross-compile way as a main 
 method of its usage? (GDC/LDC)

 Many decades the classical C and some limited set of C++ plays 
 in this area, but nowadays embedded (Arduino, Raspberry, etc) 
 raised its usage among hobbits and not so qualified and 
 non-professional programmers and users. Maybe this directon can 
 push the D language in its evolution and popularity, as people 
 now needs some multiplatform optimizing compiler for rich and 
 handy language but not so complex as classical C, or 
 mbed/Arduino-like C++ dialects?


D is about in the same league as C++. D has better C (or stripped 
object.d) in order to compile directly to object code without the 
need of any library. When you try to port the library, C++ and D 
both has the problem with that you need to port a lot of 
functionality in the STL/Clib first.

You have to keep in mind you need to separate small embedded 
systems (about 128K and less) IoT, multimedia. IoT and multimedia 
requires a full "rich OS" with a graphics stack and networking, 
which means full D and you would probably not use better C or 
similar.

For Arduinos and such which is commonly call microcontrollers, D 
can serve a purpose with better C. To be honest, **the advantage 
of D starts to pay off when complexity goes up**. If you want to 
blink a LED, then additional features of D isn't that much worth 
it and you probably will use the SDK that comes with the 
microcontroller.
Dec 08 2023
parent Denis Feklushkin <feklushkin.denis gmail.com> writes:
On Friday, 8 December 2023 at 22:45:05 UTC, IGotD- wrote:


 You have to keep in mind you need to separate small embedded 
 systems (about 128K and less) IoT, multimedia. IoT and 
 multimedia requires a full "rich OS" with a graphics stack and 
 networking, which means full D and you would probably not use 
 better C or similar.


Could be classified by other way: embedded which does not 
allocates memory during normal operation and which allocates

And, because of D has ability to easy and gracefuly handle 
allocation errors, so we can assume that D is better suited than 
C++ for "embedded multimedia" role
Dec 08 2023