A Case for Oxidation: A potential missed opportunity for D

Jonathan M Davis newsgroup.d at jmdavisprog.com
Fri Jun 29 11:47:51 UTC 2018


On Friday, June 29, 2018 10:55:27 kinke via Digitalmars-d wrote:
> On Friday, 29 June 2018 at 10:00:09 UTC, Radu wrote:
> > While not necessarily targeting bare metal, I'm very interested
> > in a working version of @safe dlang. I believe that dlang with
> > betterC, @safe, C/C++ inter-op and dip1000 will be huge for
> > replacing C/C++.
>
> I'd love to hear some reasons for -betterC from a competent guy
> like yourself. I simply don't get what all the fuzz is about and
> what people expect to gain from losing druntime (and language
> features depending on it) and non-template-only Phobos. I
> understand the separate 'minimal runtime' need for bare metal (no
> Type- and ModuleInfos etc.), but I can't help myself in seeing
> betterC as, nicely put, worseD. I acknowledge that it seems to
> attract wide-spread interest, and I'd like to understand why.

I completely agree that -betterC means -worseD, and in general, I see no
reason to mess with it if I can avoid it. However, if you're trying to use D
from a C or C++ application, the fact that you have to deal with starting up
and shutting down druntime definitely causes problems (as does the GC - not
because of performance but due to the fact that you then have non-D code
interacting with GC-allocated memory, and that gets complicated). It's far
easier to have C/C++ code call D code that has a C API and doesn't require
an additional runtime. The result is definitely worse than just using D, but
if you're stuck with having C/C++ and are trying to use D from within that
environment, -betterC gives you a way. I'm honestly not sure that using a
stripped down D is enough better than using C/C++ to be worth it (especially
if you're stuck using D like C when you could be using C++ instead), but
there's certainly an argument to be made for it.

The other place that -betterC has real value is when porting a C/C++
application to D. By porting portions of it to -betterC, you can do the
porting piecemeal, and then once the porting is complete, you can ditch
-betterC and use proper D. In contrast, if you tried to go straight to
full-on D, you tend to have to port large portions of the program at a time
(perhaps even the entire thing), which is much harder to do. In such a case,
-betterC is really just a stepping stone and not something that you'd want
to use normally.

However, if you don't need to hook D into an existing C/C++ application (be
it to add functionality or to actually port the code), then personally, I
think that -betterC is definitely just -worseD and an utter waste of time.
But some folks (especially those who are really biased against the GC) do
seem to leap at the idea as if it fixes D.

- Jonathan M Davis



More information about the Digitalmars-d mailing list