A Case for Oxidation: A potential missed opportunity for D

[Radu]

On Friday, 29 June 2018 at 10:55:27 UTC, kinke 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.

There technical and political reason here.

BetterC offers a clean no-overhead strictly enforced subset of 
the language. This is great for porting over existing C code base 
and also for creating equivalent libs in D but without worrying 
that you carry over baggage from the D run-time.

It also serves as a good tire 1 target when porting D to other 
platforms. WebAssembly is one of those odd platforms were D could 
shine, and having betterC greatly easy the effort of porting it 
over (even though so far nobody stepped out to do this).

C is a beast and its hardcore programmers will not touch anything 
that has typeinfo, gc or classes. Selling betterC to them (this 
includes teammates) is a lot easier, you can show them the 
assembly on godblot.org and they see no extra fat is added. @safe 
is the added bonus and the final nail in the coffin to ditch C.

But ultimately betterC is also a sign of the design failure on 
both dlang and druntime in the way that it wasn't conceived to be 
modular and easier to use in a pay-as-you-go fashion. Until the 
GC and typeinfo is truly optional and reserved only for the top 
layers of the standard library betterC is the best we have.