Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

D Language accepted for inclusion in GCC

gcc.gnu.org

Post reply on HN
Print view View original

131–140 of 235 posts

Re: D Language accepted for inclusion in GCC

#131

Post by pjmlp »

int_19h wrote: post #119
baybal2 wrote: post #90

Earlier quoted context omitted.

Slowly but steadily. Given the fact that D has not managed to die when it had so many chances to, I tell that D has better chance at mass adoption as "a better C++" than the current wave of Swift/Rust/Go that rely on "life support" from a corporate donor.

I don't think it's meaningful to put Swift, Rust and Go in a single bucket when comparing them. They're languages targeting different levels of abstraction, with very different approaches as a result. Some people refer to all of these as "better C++", but it's meant in very different and incomparable ways. For example, Rust is ostensibly a "better C++" in a sense that it retains the low-level, zero-overhead (no GC) e…

> Others are "something better than C++ for most apps you'd write in C++ today".

As big C++ fan and language geek, I am pretty confident that if Java and .NET had taken the route of all other alternatives in the 90's (Oberon, Eiffel, Modula-3, Delphi,...), C and C++ would be less relevant today than they turned out to be.

This because many people make use of them, just because they are the only languages they know about compilers that produce AOT executables, with the option of static linking them.

Maybe even Longhorn would have been a success, instead of having to wait for UWP with .NET Native.

Re: D Language accepted for inclusion in GCC

#132

Post by donatj »

int_19h wrote: post #119
baybal2 wrote: post #90

Earlier quoted context omitted.

Slowly but steadily. Given the fact that D has not managed to die when it had so many chances to, I tell that D has better chance at mass adoption as "a better C++" than the current wave of Swift/Rust/Go that rely on "life support" from a corporate donor.

I don't think it's meaningful to put Swift, Rust and Go in a single bucket when comparing them. They're languages targeting different levels of abstraction, with very different approaches as a result. Some people refer to all of these as "better C++", but it's meant in very different and incomparable ways. For example, Rust is ostensibly a "better C++" in a sense that it retains the low-level, zero-overhead (no GC) e…

I will argue that Go is more of a better C than a better C++

Re: D Language accepted for inclusion in GCC

#133

Post by Dylan16807 »

_delirium wrote: post #81
yellowapple wrote: post #41

Earlier quoted context omitted.

The usual term for that sort of arrangement would be "shared source".

I've seen "source-available" as well. But yes, it's not "open source" if it's proprietary source that you can only look at.

You can do a lot more than look at it. You can modify it, compile it, share your modifications, and share your binaries with your game.

The one major thing you can't do is redistribute the base source code. That's a big thing, and disqualifies it from being open source, but let's not pretend there is no value in the source code access.

Re: D Language accepted for inclusion in GCC

#134

Post by pirocks »

int_19h wrote: post #129

Is there a D IDE with good code completion and refactoring support? Last time I tried it, all that I've seen were pretty bad at it - handling the simple stuff fine, but breaking down on more complicated stuff, metaprogramming especially (kinda like most C++ IDEs did 8 years ago or so).

Due to the high complexity of d and the small community, there are currently no "great " ides.

Re: D Language accepted for inclusion in GCC

#135

Post by WalterBright »

nialv7 wrote: post #84
fithisux wrote: post #77

While I like D and use it for scientific work, wwo "omissions" leave me a bitter taste. Nothrow and Pure are not part of the type signature of functions and consequently the compiler has limited inference about these. However I will keep using it unless something better comes up. C++/C# are not an option for me since I found D.

I thought they are?

They are.

Re: D Language accepted for inclusion in GCC

#136

Post by WalterBright »

eco wrote: post #74

This is basically the work of one tireless man; Iain Buclaw. Many thanks to him for putting in so much time and energy into this. It took 6 years from first submission to get it in. Here are the slides from his 2017 DConf talk about the work that went into making this happen: http://dconf.org/2017/talks/buclaw.pdf

Just goes to show how one person, with relentless persistence, can still make a huge difference these days. Congratulations, Iain!

Re: D Language accepted for inclusion in GCC

#137

Post by WalterBright »

Veratyr wrote: post #121
baybal2 wrote: post #90

Earlier quoted context omitted.

Slowly but steadily. Given the fact that D has not managed to die when it had so many chances to, I tell that D has better chance at mass adoption as "a better C++" than the current wave of Swift/Rust/Go that rely on "life support" from a corporate donor.

I don't think that's true. Despite their corporate life support and relatively young ages, Go, Rust and Swift are all in the top 25 most active languages on Github ( https://gist.github.com/alysonla/e14c01ec7a0d2823e7317f7b58b... ) and D is not (and never has been). The masses have had a long time to adopt D and I wouldn't get my hopes up simply because it's not dead yet.

So far 2017 has been a banner year for D, with the fully open sourcing of it and now the gcc incorporation!

Re: D Language accepted for inclusion in GCC

#138

Post by kaleidic »

Veratyr wrote: post #121
baybal2 wrote: post #90

Earlier quoted context omitted.

Slowly but steadily. Given the fact that D has not managed to die when it had so many chances to, I tell that D has better chance at mass adoption as "a better C++" than the current wave of Swift/Rust/Go that rely on "life support" from a corporate donor.

I don't think that's true. Despite their corporate life support and relatively young ages, Go, Rust and Swift are all in the top 25 most active languages on Github ( https://gist.github.com/alysonla/e14c01ec7a0d2823e7317f7b58b... ) and D is not (and never has been). The masses have had a long time to adopt D and I wouldn't get my hopes up simply because it's not dead yet.

Garbage in, garbage out. Github's language detection isn't perfect, and people in the D community simply aren't particularly focused on marketing and popularity contests. See here for example :

http://www.mail-archive.com/digitalmars-d-learn@puremagic.co...

Not only is it not quite dead yet, it's growing rapidly : http://erdani.com/d/downloads.daily.png

DMD downloads direct from home page only.

Re: D Language accepted for inclusion in GCC

#139

Post by kaleidic »

WalterBright wrote: post #137
Veratyr wrote: post #121

Earlier quoted context omitted.

I don't think that's true. Despite their corporate life support and relatively young ages, Go, Rust and Swift are all in the top 25 most active languages on Github ( https://gist.github.com/alysonla/e14c01ec7a0d2823e7317f7b58b... ) and D is not (and never has been). The masses have had a long time to adopt D and I wouldn't get my hopes up simply because it's not dead yet.

So far 2017 has been a banner year for D, with the fully open sourcing of it and now the gcc incorporation!

Plus betterC and gpu target.

Re: D Language accepted for inclusion in GCC

#140

Post by WalterBright »

copx wrote: post #15
iamNumber4 wrote: post #10

Earlier quoted context omitted.

One of D's goals is to be ABI compatible with C and C++, ABI compatibility with C is 100% as I understand it. C++ is a work in progress. What is ABI compatiblity? in a nutshell it let's you use libraries from another programming language. In D, all you need is a D file that describes the C/C++ library as a wrapper so the D compiler knows what you are using. This means D will build upon everything that already exists…

How would that even work? Modern C++ libraries are largely templates, templates which must be instantiated at compile-time i.e. you need a full C++ compiler to use C++ libraries directly. Said compiler must somehow work together with the D compiler here, which should lead to god-awful memory use, compilation time, and error messages.

Yes, it is amazing that D can work with C++ templates! I gave a talk on how it is done here:

https://www.youtube.com/watch?v=IkwaV6k6BmM

Post reply on HN