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

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

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.

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.

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.

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

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