On 5 March 2017 at 06:45, Ilya Yaroshenko via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On Saturday, 4 March 2017 at 16:43:21 UTC, Moritz Maxeiner wrote: >> >> On Saturday, 4 March 2017 at 15:35:13 UTC, Ilya Yaroshenko wrote: >>> >>> [...] >>>> >>>> >>>> my 1 cent: we should stop trying to convert C++ users. >>> >>> >>> Please, do no push devs to do not do something. There are two directions: >>> betterC and DRuntime. >> >> >> I've tried to follow the "betterC" discussion, but so far a precise >> specification of what betterC is supposed to be eluded me. What I got was >> that you seem to be judging druntime to be too heavyweight and want >> something more lightweight, but I was never clear on what exactly. >> >>> I believe in betterC and betterC target is C/C++ industry. Old D users >>> are happy with DRuntime and growing Phobos. >> >> >> 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. > >> This doesn't mean I'm happy with druntime and phobos, though. > > > Yep. Additions to std.range like orElse will make idiomatic Phobos code > slower then C++ and Scala. It is not clear when you do a benchmark for > single implementation, but idiomatic combinations of D Ranges will became > slow. > >>> This ways are not compatible at least for now. >> >> >> I must have missed that: Are you saying that someone using druntime in his >> application will not be able to use "betterC" libraries? > > > No, betterC libraries can be used by D apps like a common C libs. >
Ha! Did no one tell you any horror stories about people dealing with C++ ABIs? If this is the essentially the crux of your problem, then you are barking up the wrong tree in blaming druntime for the mess we are allegedly in. >>> Mir libraries are going to be betterC, the next great betterC goal is >>> DCV. >>> >>> Ilya >> >> >> Would it be possible for you to provide a precise specification of what >> exactly betterC is going to be? Or, if that already exists, and I have >> missed it, point me to it? > > > 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 > > Why without DRuntime? I had explained this multiple times. > 1. DRuntime has not stable ABI between versions I was curious to see if there were any ABI changes in GDC with functions that it generates code for, and the first I found was 5 years ago, where _aaDelp (DMD didn't support a non-variadic 'delete aa' at the time) had it's return type changed from void to bool. Changes since then have either been functions added or functions removed - but only *after* the compiler stopped generating calls to it some 2 years down the line. So I am a bit amused when you say that ABI is not stable. > 2. DRuntime has not stable ABI between compilers I think you mean common ABI. GDC and LDC should be compatible on anything that is extern(C). Feel free to request an apology from DMD however for using a made up calling convention, which has single-handedly caused the biggest rift between us and them. > 3. DRuntime depends on GC, D GC is slow, and because D design GC will always > will be slow. > > 1,2,3 are important for real world business. Most of existing D users do not > need 1-3 (otherwise they would switch to C). So, I do not expect any > understanding from the community about my opinion :P I think this deserves only a blink. Considering that there are some companies out there, using real-time applications that make use of D's GC also (of course, within reason). The only feedback I can offer you here is that not only should you expect community to not understand you, real world business won't understand you either.