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.
