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.
