On Friday, 22 December 2017 at 16:17:33 UTC, Dan Partelly wrote:
> On Friday, 22 December 2017 at 15:23:51 UTC, Russel Winder wrote:
>> I think we are now in a world where Rust is the zero cost abstraction language to replace C and C++, except for those who are determined to stay with C++ and evolve it.
>
> Why should we settle for this ? D code (efortless) is easier to read then Rust. I assume this to be true for a lot of programmers who know C/C++. It also introperates very well with C, which is great boon, since at low level we live on the shoulder of a titan written in C.  It has tremnedous features, and ironically the best of them could have been designed to not relay on GC. As most , if not all, of the features offered by its library could have been done with no GC.
>
>>
>> D, like Go, should glory in having a GC and just go with it.
>>
>> Of course this does not mean the GC as is is good enough. Go is on its
>> third I believe, and Java on it's fifth.
>
> A good implementation at library level of GC would mean that I can use one single language
> in all areas of system programming. Or at least, a implementation where std:: and core features of language should not relay on GC. This, IMO is an advantage not to be neglected. A better C mode with a very powerfull high level standard library (like std:: ), exceptions, RAII, classes (yes, why not ) typeid would be a very big step ahead. All those could be done without having to worry about existence of GC. C++ has all those.
>
> IMO the key here is the standard libray of the language. Nothing in it should relay  on the existence of GC. Why, why, does it have to depend on GC and hence automatically disqualify itself from a better C world ? The C runtime ezposed by core is powerfull, but imagine having std:: power in better C as well. I really lament this.
>
> You could have the best of the two worlds.

You seem not to have read the original link and Walter's first post: why would we expend all that effort on a small, shrinking niche of the language market that is populated by a couple thousand diehard programmers who won't look at any new language?

That's not to say the core team is ignoring that market, as the betterC mode is geared toward some of them who don't need all the features you want, but realistically it will take years for D to provide all D features with an easy choice of GC or not, if it's even technically feasible.  Given that GC is already here and addresses a much bigger market, there's no point in Osborning all that's available _today_ by forever dreaming for a fully no-GC stdlib that's not going to be here anytime soon.

If that's what you really want though, I suggest you pitch in, as Mike Franklin has being doing recently:

https://github.com/dlang/dmd/pulls/JinShil

On Friday, 22 December 2017 at 16:17:33 UTC, Dan Partelly wrote:
> On Friday, 22 December 2017 at 15:23:51 UTC, Russel Winder wrote:
>> I think we are now in a world where Rust is the zero cost abstraction language to replace C and C++, except for those who are determined to stay with C++ and evolve it.
>
> Why should we settle for this ? D code (efortless) is easier to read then Rust. I assume this to be true for a lot of programmers who know C/C++. It also introperates very well with C, which is great boon, since at low level we live on the shoulder of a titan written in C.  It has tremnedous features, and ironically the best of them could have been designed to not relay on GC. As most , if not all, of the features offered by its library could have been done with no GC.
>
>>
>> D, like Go, should glory in having a GC and just go with it.
>>
>> Of course this does not mean the GC as is is good enough. Go is on its
>> third I believe, and Java on it's fifth.
>
> A good implementation at library level of GC would mean that I can use one single language
> in all areas of system programming. Or at least, a implementation where std:: and core features of language should not relay on GC. This, IMO is an advantage not to be neglected. A better C mode with a very powerfull high level standard library (like std:: ), exceptions, RAII, classes (yes, why not ) typeid would be a very big step ahead. All those could be done without having to worry about existence of GC. C++ has all those.
>
> IMO the key here is the standard libray of the language. Nothing in it should relay  on the existence of GC. Why, why, does it have to depend on GC and hence automatically disqualify itself from a better C world ? The C runtime ezposed by core is powerfull, but imagine having std:: power in better C as well. I really lament this.
>
> You could have the best of the two worlds.

Regarding GC being built into the core language, from [the D faq](https://dlang.org/faq.html):

"**Can't garbage collection be done in C++ with an add-on library?**

Yes, I use one myself. It isn't part of the language, though, and requires some subverting of the language to make it work. Using gc with C++ isn't for the standard or casual C++ programmer. Building it into the language, like in D, makes it practical for everyday programming chores."

I'm new to D. Coming primarily from Python these days, I'm looking at D not as a better C++ (haven't used that in many years), but as a better Python.

On Friday, 22 December 2017 at 18:59:34 UTC, John Gabriele wrote:
> I'm new to D. Coming primarily from Python these days, I'm looking at D not as a better C++ (haven't used that in many years), but as a better Python.

I'm quite similar. New to D (been using it for a month now). I see it as a better C#. The GC is great to have. Even better is the fact that D makes it easy to bypass it where necessary and the language gives me more control over my program if I need.

I wish D would stop bending over backwards to appease C/C++ programmers. I think D would have more success branding itself as a general purpose language and letting itself become the language it should be, not the language some C++ programmer wants but is never going to use anyway.

On Friday, 22 December 2017 at 17:21:12 UTC, Joakim wrote:
> You seem not to have read the original link and Walter's first post: why would we expend all that effort on a small, shrinking niche of the language market that is populated by a couple thousand diehard programmers who won't look at any new language?


 Empiricall Id say that a lot of those programmers are interested in both old and new languages, from Lisp to D. But nevermind that. Those people are not idiots really. They would use any language which gets the job done, and they would use as high level as possible to get the job done. They look and then they go back from practical reasons. And a 10% market of C programmers is not really small niche. D could have got a lot of those, if it made just one more good decision regarding the "how" of GC and libs. The IOT is upon us, automation is upon us, embeded devices slowly become ubiquitous in cosumer market, while a lot of languages shoot themselves in the foot from beeing a part of this market with poor decisions.


>  Given that GC is already here and addresses a much bigger market, there's no point in Osborning all that's available _today_ by forever dreaming for a fully no-GC stdlib that's not going to be here anytime soon.

Sure. This is why I said I lament the choiche done. Today the vast std lib of D should have been not GC dependent. So IMO, D made a good decision having GC (they did a lot of great decsions btw, D is phenomenal good IMO) and D made a very bad decision having a std lib dependant on GC, convenience language features dependant by gc (vectors , hashes and the like belong to the library ), and core language features dependant on GC (classes / exceptions whatever)

So there you have it. Regarding GC, in my opinion D made both a good decision and a bad one.

On Saturday, 23 December 2017 at 01:12:53 UTC, Dylan Graham wrote:
> language it should be, not the language some C++ programmer wants but is never going to use anyway.

Ironically, D is so close to beeing the language a C++ programmer would really use that you can smell it. It doesnt have to bend, since it got so close with a lot of good decisions. D is the first language Im aware of which  has the potential to satisfy the needs of a very large portion of the market,

On Friday, 22 December 2017 at 16:17:33 UTC, Dan Partelly wrote:
> Why should we settle for this ? D code (efortless) is easier to read then Rust.
Such statement is highly controversial, since it can be said about C/C++, D and most other languages as well.

On 12/22/2017 7:23 AM, Russel Winder wrote:
> I think we are now in a world where Rust is the zero cost abstraction
> language to replace C and C++, except for those who are determined to
> stay with C++ and evolve it.

Maybe it is. But that is not because D isn't up to the task. I've converted a large program from C to D (Digital Mars C++'s front end) with -betterC and it really is a zero cost abstraction. The memory safety benefits are there (DIP 1000), RAII is there, nested functions, array bounds checking, template metaprogramming, CTFE, etc.

I expect to be upgrading a lot of older C code I still use in this manner. I just don't want to work in C anymore. Furthermore, I do not need to re-engineer the C code to convert it to D - it can be done pretty much by rote, unlike Rust.

D as betterC really is a game changer, for anyone who cares to give it a try.

On Saturday, 23 December 2017 at 09:10:25 UTC, Walter Bright wrote:
>
> D as betterC really is a game changer, for anyone who cares to give it a try.

Walter, would you expect a std suitable for betterC to be specified in the language ? You could name it Deimos.

Russel Winder wrote:

> I think we are now in a world where Rust is the zero cost abstraction
> language to replace C and C++, except for those who are determined to
> stay with C++ and evolve it.

sorry, but it is not zero cost. we have alot of C and C++ code. converting it to Rust is not zero cost at all. and using it as-is won't make our codebases any better.

but with D, i can say that converting C code is almost zero cost. i did alot of C->D ports, and most of the work was done with "sed". then i have to run dmd and add some casts and other simple things (sure, i should finally write an automatic converter, but... you know that "ok, next time" kind of self-promises ;-).

i also ported some C++ codebases, and it is almost equally easy. mostly due to the fact that people tend to avoid "modern" C++ features and metaprogramming: it is still hard to use with C++. (with D, btw, i started to use templates even before i fully realised that i am using templates ;-)

what i want to say (and didn't, as usual) is that Rust is not zero cost due to exisiting codebases. either you have to invest alot of time and efforts to port those codebases, or you have to use both Rust and C/C++, and suffer the consequences.

and with D, you can port all your code, and use one language, investing *much* less efforts than you'd have with Rust/Go. plus, you'll get all the things D has to offer, for free.

that is, D actually has *no* competitors. if not google and mozco, people won't even start talking seriously about Go/Rust. yet even in this unfair race, D presence is constantly growing. just wait a little, and you'll see a dawn of Rust and Go. and D will be still there, standing strong and proud. ;-)

On Friday, 22 December 2017 at 15:23:51 UTC, Russel Winder wrote:
> I think we are now in a world where Rust is the zero cost abstraction language to replace C and C++, except for those who are determined to stay with C++ and evolve it.
>

Well..there are plenty who are determined to stay with C++ and evolve it... so I don't see a replacement for C++ coming anytime soon ;-)

In fact, I wouldn't be surprised if there were a C++ renaissance in the not too distance future..(don't hold me to that though)

As for C, everyone seems to be trying to make a 'better' C, including new kid on the block , Zig ("Zig is a programming language which is intended to replace C") - http://ziglang.org/

But some of these so called better C projects just change the syntax too much, and the learning curve becomes too much...at least for me.. as I don't have that kind of patience anymore, and much of the syntax change is just ideologically driven anyway.

D really does have the right balance of 'maintaining syntax' (for the most part) that a C developer can instantly recognise and begin working with.

= still = =

Out of Go, Rust and D, I find D to be 'the most' refreshing and pleasant alternative to C, and I doubt anyone or anything could convince me otherwise.

D is also *not* being driven by corporate heads, which means it's more free to innovate and become better.

Having said that, nothing is better than C.

And I wish -betterC was renamed -slimD, -saferC, or perhaps, -niceAlternativeToC