www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A Case for Oxidation: A potential missed opportunity for D

reply Mike Franklin <slavo5150 yahoo.com> writes:
Please allow me to bring your attention to an interesting 
presentation about  choosing a modern programming language for 
writing operating systems:

https://www.youtube.com/watch?v=cDFSrVhnZKo

It's a good talk and probably worth your time if you're 
interested in bare-metal systems programming.  The presenter 
mentions D briefly in the beginning when he discussed how he made 
his choice of programming language.

He shows the following (probably inaccurate) matrix.

Lang    | Mem Safety | Min Runtime | Strong Type Syst. | 
Performance
C       |            | x           |                   | x
C++     |            | x           |                   | x

D       | x          |             | x                 | x
Go      | x          |             | x                 | x
Rust    | x          | x           | x                 | x
Java    | x          |             | x                 | x
Haskell | x          |             | x                 |
Cycle   | x          | x           | x                 | x

It appears the deal-breaker for D was the lack of "minimal 
runtime".  Of course D has -betterC and, with 2.079, a way to use 
some features of D without the runtime, but he also goes on to 
discuss the importance of memory safety in his application of the 
language.

I hope we'll see something competitive with DIP25, DIP1000, and 
the `scope` storage class, namely *memory safety without a 
runtime*.

I'm currently waiting for 2.081 to reach LDC and GDC, and then I 
have a few ideas I'd like to begin working on myself, but I never 
have a shortage of ideas, just a shortage of time and energy.

Enjoy!

Mike
Jun 29 2018
next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Friday, 29 June 2018 at 09:25:08 UTC, Mike Franklin wrote:


 He shows the following (probably inaccurate) matrix.


Sorry, I messed up typing out that matrix.  Here are a few 
corrections, but you can just see the real think the video here:  
https://youtu.be/cDFSrVhnZKo?t=260

Lang    | Mem Safety | Min Runtime | Strong Type Syst. | 
Performance
C       |            | x           |                   | x
C++     |            | x           |                   | x

D       | x          |             | x                 | x
Go      | x          |             |                   | x
Nim     | x          |             | x                 | x
Rust    | x          | x           | x                 | x
Java    | x          |             | x                 | x
Haskell | x          |             | x                 |
Cyclone | x          | x           | x                 | x

Mike
Jun 29 2018
prev sibling next sibling parent reply Radu <void null.pt> writes:
On Friday, 29 June 2018 at 09:25:08 UTC, Mike Franklin wrote:

 Please allow me to bring your attention to an interesting 
 presentation about  choosing a modern programming language for 
 writing operating systems:

 https://www.youtube.com/watch?v=cDFSrVhnZKo

 It's a good talk and probably worth your time if you're 
 interested in bare-metal systems programming.  The presenter 
 mentions D briefly in the beginning when he discussed how he 
 made his choice of programming language.

 He shows the following (probably inaccurate) matrix.

 Lang    | Mem Safety | Min Runtime | Strong Type Syst. | 
 Performance
 C       |            | x           |                   | x
 C++     |            | x           |                   | x

 D       | x          |             | x                 | x
 Go      | x          |             | x                 | x
 Rust    | x          | x           | x                 | x
 Java    | x          |             | x                 | x
 Haskell | x          |             | x                 |
 Cycle   | x          | x           | x                 | x

 It appears the deal-breaker for D was the lack of "minimal 
 runtime".  Of course D has -betterC and, with 2.079, a way to 
 use some features of D without the runtime, but he also goes on 
 to discuss the importance of memory safety in his application 
 of the language.

 I hope we'll see something competitive with DIP25, DIP1000, and 
 the `scope` storage class, namely *memory safety without a 
 runtime*.

 I'm currently waiting for 2.081 to reach LDC and GDC, and then 
 I have a few ideas I'd like to begin working on myself, but I 
 never have a shortage of ideas, just a shortage of time and 
 energy.

 Enjoy!

 Mike


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++.

Not long ago I tried to create a library in dlang that is coded 
betterC and  safe. The idea is to have the library core in dlang 
and automatically generated C and C++ wrappers at compile time 
for allowing the library to be used from those languages or 
others capable to link to the C API.

Unfortunately bugs in betterC and dip1000 stopped progress (most 
of where fixed already). So waiting for LDC to catch up and give 
it a try again. Also looking fwd to be able to use C++ classes in 
betterC.

I think if my library, or others, can make it, we could have a 
strong showcase on why dlang is better on so many levels.

The key is focusing on fixing betterC and  safe (dip1000) and 
keep quality standards high.
I think you did a great job already in fixing many of the issues, 
so thanks!
Jun 29 2018
parent reply kinke <noone nowhere.com> writes:
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.
Jun 29 2018
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 29/06/2018 10:55 PM, 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.


It greatly simplifies development against existing C/C++ codebases.
To some people (for their given use cases) this can be a very good thing.

Removing barriers for adoption is a very noble but more importantly wise 
thing to do, and we should all aim to do it.
Jun 29 2018
parent reply kinke <noone nowhere.com> writes:
On Friday, 29 June 2018 at 11:04:30 UTC, rikki cattermole wrote:

 It greatly simplifies development against existing C/C++ 
 codebases.


How so? By telling people you can express C++:

void cpy(char *dst, const char *src, size_t size)
{
     for (size_t i; i < size; ++i)
         dst[i] = src[i];
}

elegantly and safe like this in D:

void cpy(void[] dst, void[] src) { dst[] = src[]; }

unless they are using betterC (undefined reference to 
'_d_arraycopy')? Just to highlight one lost language feature.
Jun 29 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 29/06/2018 11:17 PM, kinke wrote:

 On Friday, 29 June 2018 at 11:04:30 UTC, rikki cattermole wrote:

 It greatly simplifies development against existing C/C++ codebases.


 
 How so? By telling people you can express C++:
 
 void cpy(char *dst, const char *src, size_t size)
 {
      for (size_t i; i < size; ++i)
          dst[i] = src[i];
 }
 
 elegantly and safe like this in D:
 
 void cpy(void[] dst, void[] src) { dst[] = src[]; }
 
 unless they are using betterC (undefined reference to '_d_arraycopy')? 
 Just to highlight one lost language feature.


It is a language feature yes, and it doesn't define /how/ it gets 
implemented.

In fact the spec[0][1] implies that it generates highly optimized 
assembly, not go and call a function.

[0] https://dlang.org/spec/simd.html
[1] https://dlang.org/spec/arrays.html#array-copying
Jun 29 2018
parent reply kinke <noone nowhere.com> writes:
On Friday, 29 June 2018 at 11:24:52 UTC, rikki cattermole wrote:

 It is a language feature yes, and it doesn't define /how/ it 
 gets implemented.


That's besides my actual point though (and I haven't even 
mentioned missing class support, which is everything but helping 
with developing against existing C++ codebases).
My question is: what do people expect to gain by not linking in 
druntime and Phobos? Is there a feeling the binaries are 
unnecessarily bloated (-> minimal runtime)? Is it making 
cross-compilation harder (LDC has the ldc-build-runtime tool for 
that)? Is it the cozy feeling that the GC won't used at all? ...
Jun 29 2018
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 29/06/2018 11:36 PM, kinke wrote:

 On Friday, 29 June 2018 at 11:24:52 UTC, rikki cattermole wrote:

 It is a language feature yes, and it doesn't define /how/ it gets 
 implemented.


 
 That's besides my actual point though (and I haven't even mentioned 
 missing class support, which is everything but helping with developing 
 against existing C++ codebases).


It was besides mine as well.


 My question is: what do people expect to gain by not linking in druntime 
 and Phobos? Is there a feeling the binaries are unnecessarily bloated 
 (-> minimal runtime)? Is it making cross-compilation harder (LDC has the 
 ldc-build-runtime tool for that)? Is it the cozy feeling that the GC 
 won't used at all? ...


Simple, it isn't there to prevent technical issues, it is to remove 
mental barriers.

There is a field dedicated to researching this, called Human Computer 
Interaction (HCI) and so far, it seems to have been what was needed for 
its users.

You and I do not suffer this block. But many do, and it is as hard and 
concrete to them as not having actual proper shared library support is 
to me.
Jun 29 2018
prev sibling next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
On Friday, 29 June 2018 at 10:55:27 UTC, kinke wrote:

 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


I *completely* agree. However, I have nothing against betterC as 
long as people like me, who do enterprise software, are 
guaranteed to see "-betterD" option (here I actually mean - as 
long as the "regular" D is improving)...
Jun 29 2018
prev sibling next sibling parent reply Radu <void null.pt> writes:
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.
Jun 29 2018
parent kinke <noone nowhere.com> writes:
On Friday, 29 June 2018 at 11:31:17 UTC, Radu wrote:

 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.


Okay, thanks for the rationale. If it's mainly about 
Type-/ModuleInfos bloat and the GC, the compiler fed with 
-betterC could also

* continue to elide the Type-/ModuleInfo emission,
* additionally error out on all implicit druntime calls to the GC,
* still link in druntime and Phobos.

That should make more things work, incl. the above slice copy and 
(manually allocated) extern(C++) classes.
Jun 29 2018
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Jun 29 2018
parent kinke <noone nowhere.com> writes:
On Friday, 29 June 2018 at 11:47:51 UTC, Jonathan M Davis wrote:

 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.


Good point, thanks.
Jun 29 2018
prev sibling next sibling parent SrMordred <patric.dexheimer gmail.com> writes:
  and non-template-only Phobos.



 unless they are using betterC (undefined reference to 
 '_d_arraycopy')?


Are you sure about this?

//flags: -betterC -noboundscheck
extern(C):
void main()
{
     import core.stdc.stdlib;
     int[] x = ( cast(int*) malloc( int.sizeof * 10 ) )[0 .. 10];
     int[] y = ( cast(int*) malloc( int.sizeof * 10 ) )[0 .. 10];

     import std.algorithm : map;

     x.map!( x => x * 2 );

     x[] = y[];
}

//compiles and works ok.
Jun 29 2018
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2018-06-29 12:55, kinke wrote:


 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.


You can potentially do a lot at compile time (which you cannot do in C 
or C++) while at the same time have a requirement of not using a 
runtime. There's a talk, I think at a Dconf, where the speaker was using 
D on bare metal. He used CTFE to parse a PDF file with the specification 
for op codes or something similar. The CTFE code generate some table or 
other code for the op codes. This resulted in the code always being up 
to date with the specification.

I've written a tiny plugin for an application where I used a tiny part 
of the D runtime. I didn't link with it but instead inlined the 
functions I needed directly in the plugin. For example, array copying.

There are several nice features that can be used without the runtime, like:

* Strings and arrays carry their length
* foreach
* Array slicing
* Compile time features


-- 
/Jacob Carlborg
Jun 29 2018
prev sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 29 June 2018 at 09:25:08 UTC, Mike Franklin wrote:

 Please allow me to bring your attention to an interesting 
 presentation about  choosing a modern programming language for 
 writing operating systems:

 https://www.youtube.com/watch?v=cDFSrVhnZKo

 It's a good talk and probably worth your time if you're 
 interested in bare-metal systems programming.  The presenter 
 mentions D briefly in the beginning when he discussed how he 
 made his choice of programming language.

 He shows the following (probably inaccurate) matrix.

 Lang    | Mem Safety | Min Runtime | Strong Type Syst. | 
 Performance
 C       |            | x           |                   | x
 C++     |            | x           |                   | x

 D       | x          |             | x                 | x
 Go      | x          |             | x                 | x
 Rust    | x          | x           | x                 | x
 Java    | x          |             | x                 | x
 Haskell | x          |             | x                 |
 Cycle   | x          | x           | x                 | x

 It appears the deal-breaker for D was the lack of "minimal 
 runtime".  Of course D has -betterC and, with 2.079, a way to 
 use some features of D without the runtime, but he also goes on 
 to discuss the importance of memory safety in his application 
 of the language.

 I hope we'll see something competitive with DIP25, DIP1000, and 
 the `scope` storage class, namely *memory safety without a 
 runtime*.

 I'm currently waiting for 2.081 to reach LDC and GDC, and then 
 I have a few ideas I'd like to begin working on myself, but I 
 never have a shortage of ideas, just a shortage of time and 
 energy.

 Enjoy!

 Mike


This just isn't true.  I've written a fair amount of a linux 
distro in D without druntime/phobos or even the standard C 
library.

https://github.com/marler8997/maros
Jun 29 2018