On Friday, 24 August 2018 at 22:16:25 UTC, Jonathan M Davis wrote:
On Friday, August 24, 2018 7:46:57 AM MDT Mike Franklin via
Digitalmars-d wrote:
On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis
wrote:
> I think that you're crazy.
No, I just see more potential in D than you do.
To be clear, I'm not calling you crazy in general. I'm calling
the idea of bypassing libc to call syscalls directly under any
kind of normal circumstances crazy. There is tons of work to be
done around here to improve D, and IMHO, reimplementing OS
functions just because they're written in C is a total waste of
time and an invitation for bugs - in addition to making the
druntime code that much less portable, since it bypasses the
API layer that was standardized for POSIX systems. It's the
kind of thing that's going to cause us way more work, more
bugs, and make us that much less compatible with existing
libraries. And for what? To _maybe_ get slightly better
performance (which you probably won't get)? I honestly think
that trying to bypass libc to talk to the kernel directly is
actively worse than just using libc much as it would be great
if we somehow lived in a world where every library we used was
written in D. But the reality of the matter is that there is a
_lot_ out there already written in C where it simply makes no
sense to try to replace it. We're always going to need to
interoperate with C unless we somehow convince all of the C
developers to at least switch to -betterC (which obviously
isn't happening).
- Jonathan M Davis
You're underestimating the benefits. It's not just to be
eventually slightly faster. It makes @safe versions possible,
this in turn avoids a lot of @trusted calls, so reduces review
effort. It allows also to develop own kernels (for maybe new
hardware) without needing a c-toolchain an it makes D more self
contained. There are certainly more advantages. And if you don't
like it, the c stuff remains there for you to use.
