[Issue 14100] New: Remove barriers to D being a systems programming language

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14100

          Issue ID: 14100
           Summary: Remove barriers to D being a systems programming
                    language
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: DMD
          Assignee: nobody at puremagic.com
          Reporter: bugzilla at digitalmars.com

From: https://github.com/klamonte/cycle/blob/master/docs/no_more_d.md


•DMD emits references to C-language compiler instrinsics (__umoddi3, __udivdi3,
etc.). Any new druntime will have to provide these. It would be best if D had
its own D-language compiler intrinsics instead, which could also take advantage
of D features like pure.


•The druntime itself has many hard dependencies on libc/Win32. It should be
split into a compiler-facing "libd" part that provide the extern (D) linkage
funtions, and one or more libc-facing parts that build upon "libd". "libd"
itself only needs to call realloc() (to achieve the functions of malloc,
realloc, and free) which could be provided by a kernel or libc.


•druntime and phobos are in the end just thin wrappers around libc/Win32. A
native-D-system cannot create something like a new file abstraction API,
because in the end it must always wrap a FILE *, file descriptor, or HANDLE.
Same for sockets. To get a new abstraction, druntime needs to be able to make
syscalls.


•DMD has lost its ability to create fully-statically-linked executables. There
appears to be no momentum on getting this back. Kernels obviously are not
shared libraries.


•DMD behaves differently based on what operating system it is running on, i.e.
it is not a cross-(OS/ABI)compiler. The D language spec itself is OS and
arch-independent, with fixed sizes for all primitive types, so it should
actually be easier to make D a cross-compiler than C. This is a problem when
one wants a slightly different ABI than the host C-based OS has. DMD's current
backend license restrictions forces one to move to a different compiler.


•D has worked very hard to be a good citizen in the C/C++ space. This is a
great strength when one wants to incorporate C code into D applications.
However, it has painted D into a corner: despite having a very cool syntax that
could stand on its own for bare-metal programming, all D compilers are
hamstrung by the pre-defined C ABIs, the externally-imposed momentum regarding
shared libraries, and the C/C++ mechanisms for language features like TLS and
exception handling.

--