D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)

Petar Petar
Fri Aug 24 11:55:47 UTC 2018


On Friday, 24 August 2018 at 09:46:08 UTC, Jonathan M Davis wrote:
> On Friday, August 24, 2018 2:46:06 AM MDT Dave Jones via 
> Digitalmars-d wrote:
>> On Friday, 24 August 2018 at 04:50:34 UTC, Mike Franklin wrote:
>> > On Friday, 24 August 2018 at 04:12:42 UTC, Jonathan M Davis 
>> > wrote:
>> >
>> >
>> > It's not a problem for Phobos to depend on the C standard 
>> > library.  My goals have to do with making D, the language, 
>> > freestanding (a.k.a nimble-D).
>>
>> If the poster feature for D in the upcoming years is memory 
>> safety then how can Walter seriously consider continued 
>> dependency on libc?
>
> For any kind of normal operating system, you _have_ to use 
> libc. It's part of the OS. Some pieces could be done without 
> it, but on the whole, you use libc if you want to talk to the 
> OS. That's just life. The only exceptions I'm aware of to that 
> are embedded devices, and my understanding is that if anything, 
> such devices are more and more likely to run a fullblown OS, 
> making it that much less likely that you'd ever do anything 
> without libc.

Another notable exception is WebAssembly. Others include the 
whole distroless container trend going down to uni-kernels for 
use as a slim base for micro services. Why ship a container with 
full libc, if you're only going to use a handful of syscalls? 
That's simply a larger than necessary attack surface.

> Sure, we don't need to call C functions like strcmp, but if you 
> want to do things like I/O, you have to use the OS' API, and 
> that's libc. And yes, that means that we depend on code that's 
> not vetted via @safe, but at this point, the major OSes are 
> written in C, and they present a C API. So, accessing that 
> functionality means depending on the OS devs to have gotten it 
> right, much as it would be nice if it were verified with 
> something like @safe. The same is going to happen with plenty 
> of existing libraries that are almost certainly not going to 
> have replacements in D (e.g. postgres, ffmpeg, etc). We're 
> never going to completely escape the @safety issues introduced 
> by C. Ultimately, the best that we can do is make sure that the 
> actual D code is @safe as long as any libraries it uses are 
> @safe.
>
> - Jonathan M Davis

One of the things that makes Go successful is the quality/ease of 
use of its toolchain. They have full cross-compilation support 
out of the box because they don't rely on anything from the C 
toolchain (libc, linker, etc.). They implement implement 
everything themselves, from the syscall layer - up the whole 
stack (e.g. https://golang.org/pkg/syscall , 
https://golang.org/pkg/os/ ). Rust is also taking the same path. 
In recent times it seems that every new systems programming 
language is trying to prove that while it can interact with 
existing C libraries effortlessly, it has to be fully independent 
in order to be taken seriously. You can't replace C/C++ if you 
depend on them.
One small data point: changes to the C toolchain on Linux broke 
the druntime's backtrace support several times. If we didn't 
depend on them this probably wouldn't have happened.


More information about the Digitalmars-d mailing list