D street cred: Just a thought

[Moritz Maxeiner via Digitalmars-d]

On Sunday, 5 March 2017 at 05:45:19 UTC, Ilya Yaroshenko wrote:
> On Saturday, 4 March 2017 at 16:43:21 UTC, Moritz Maxeiner 
> wrote:
>>
>> Please don't throw all "old D users" in the same category, 
>> generalizations like that only alienate. On a related note: 
>> What I believe in is that D's community can't take another 
>> rift like Phobos/Tango, D1/D2, so I've been very skeptical 
>> regarding the value of betterC.
>
> I don't care about existing D users. Sorry about that. In the 
> same time I do not see any problem with betterC for existing D 
> users. Any betterC library can be used with Druntime like 
> either a common C library or generic D library.

I'm not asking you to, but imho it would benefit you to care 
about pushing people away from your betterC idea by 
misrepresenting them like that (as it steers from a technical 
discussion to an emotional debate). And since AFAICT you still 
use a D compiler adhering to a D spec, which likely contains 
bugs, I do think it would benefit you to care about the D 
ecosystem as a whole, since the smaller the ecosystem the 
unlikelier it becomes that bugs in the compiler get detected, 
reported, and fixed. In any case, as long as you don't intend to 
create some incompatible rift (which I wasn't clear on up till 
now) I'm happy.

>
>[...]
>
> No, betterC libraries can be used by D apps like a common C 
> libs.

Ok, thank you for the clear confirmation.

>[...]
>
> betterC is wide concept. Examples:
>
> A generic betterC library can be used to write precompiled 
> betterC libraries. Example:
> https://github.com/libmir/mir-algorithm
>
> A precompiled betterC library in binary form is a library with 
> extern(C) API that can be used without DRuntime by other 
> libraries, apps, and languages (!!!). Examples:
>
> https://github.com/tamediadigital/hll-d
> https://github.com/libmir/mir-cpuid
> https://github.com/libmir/mir-glas

Thanks for the examples, I'll have a look at how they work.

>
> Why without DRuntime? I had explained this multiple times.
> 1. DRuntime has not stable ABI between versions
> 2. DRuntime has not stable ABI between compilers
> 3. DRuntime depends on GC, D GC is slow,

Yeah, I got why you don't want to use druntime (and 1+2 are one 
one the things I'm not happy about), I just wasn't clear on 
whether you planned to replace it with something else (or just 
don't use any runtime, like you are).
This is quite interesting, since the primary reason for 
druntime's existence IIRC was the Phobos/Tango split where people 
didn't like Phobos, hence for consolidation, it was split into 
only the minimal parts to support the language features 
(druntime) and the new Phobos, so people using different standard 
libraries for D wouldn't be incompatible (since they share a 
common druntime).

> and because D design GC will always will be slow.

I was not aware of that: Am I right in understanding here that 
there is something about the language itself that inherently 
makes any attempt at using any GC slow? There is no possible way 
to implement a fast GC for D?

>
> 1,2,3 are important for real world business.

Correct me if I'm wrong, but I was under the impression that 
Sociomantic Labs was using D1 (which contains the GC that's now 
in druntime AFAIK) extensively for extremely time-sensitive tasks 
(web advertisement auctions in the microsecond range IIRC).
Druntime implements the GC and several features in it depend on 
the GC, yes, but linking against druntime doesn't - AFAIK - 
necessitate actually using any of those features, i.e. linking 
against druntime should not inherently result in any slow down. 
Regardless, I can see why one wouldn't want to link against a 
library one doesn't actually use.

> Most of existing D  users do not need 1-3 (otherwise they would 
> switch to C).

I agree that most don't seem to need them from my POV, but I 
don't agree with the assumption that people switching to C is a 
necessary conclusion from people needing them.

> So, I do not expect any understanding from the community about 
> my opinion :P

This is bordering on being derogative, though, since AFAIK we are 
supposed to be in a forum for (technical) discussions, not 
(political) debates, i.e. facts and reasoning are important as 
opposed to anyone's opinion.
These are the facts as I now see them (after your explanation):
1. You need to expose a stable ABI between compilations/releases 
of a library
2. You need to be as fast as possible.
3. 1. and 2. are hard requirements, i.e. you cannot change them.
Analysis: Does linking with druntime and/or phobos get in the way 
of 1. or 2.?
1. If you depend on any symbols from them, yes. Otherwise, no.
2. No
Conclusion: You cannot depend on any symbols from druntime or 
phobos.
Corollary: You don't need to link against druntime or phobos.

You don't need to worry (or care at all) about anyone's 
understanding of any of your opinions, you just need to lay out 
the facts and reason about them.