Live data from Hacker News

D Language accepted for inclusion in GCC

gcc.gnu.org

101–110 of 235 posts

Re: D Language accepted for inclusion in GCC

#101
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.

If I'm not mistaken, Rust is being sold as a better C, not C++. Go is being marketed as a higher level language than C and Rust focused on developing network-aware concurrent applications to fill specific server needs. I may be wrong, but I'm not really sure that they target C++ or aim to replace it, unlike D. Perhaps that's the reason why both Rust and Go managed to gain so much traction and goodwill, because they a…

> If I'm not mistaken, Rust is being sold as a better C, not C++.

We generally try to market Rust as a good language on its own merits rather than a "better X." That said, there are undoubtably comparisons to make, but the latest iteration of our marketing is "confident, productive systems programming."

Re: D Language accepted for inclusion in GCC

#102
post #96
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.

It's a bit of a stretch to cast corporate funding as a negative, especially when the direction of Swift/Rust/Go are all mostly directed by community consensus rather than the corporate middlemen signing the paychecks (see the Swift community's rejection of SE-0110, the Rust's community's rejection of struct inheritance, and the Go community's rejection of aliases). Given the opportunity I'm sure that D would delight…

D also has a foundation model, which could (I don't know anything about their financials) provide similar support to a company, but spread among companies instead.

Re: D Language accepted for inclusion in GCC

#103
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.

If I'm not mistaken, Rust is being sold as a better C, not C++. Go is being marketed as a higher level language than C and Rust focused on developing network-aware concurrent applications to fill specific server needs. I may be wrong, but I'm not really sure that they target C++ or aim to replace it, unlike D. Perhaps that's the reason why both Rust and Go managed to gain so much traction and goodwill, because they a…

I emphatically disagree that C++11 has made D irrelevant. With C++11, I still have to think about fifty possible ways to do something, old and new, and all of the possible different implications and risks and segfaults I could get with each. I don't have the luxury of ignoring all C++ written before 2011, nor can I ignore all of the design decisions before 2011 that resulted in the current status of C++ features.

After working with C++11 (or C++14 or C++17), D is such a breath of fresh air. Everything is so... easy. I can do what I want, and I don't have to worry about doing just the wrong kind of thing to get a segfault or UB. I might get stack traces at runtime if I make a mistake, or even better, compiler errors because my types didn't check correctly or my compile-time evaluations had errors, but the language is much simpler and cleaner because it's been able to throw out the baggage of C++. In fact, it's thrown it out twice, once for D1 and again for D2, what is now simply called "D".

And being able to actually throw out cruft without concerns for backwards compatibility is why D isn't irrelevant.

Re: D Language accepted for inclusion in GCC

#104
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

I'm so, so happy that after close to a decade of tireless work D is finally in gcc. I don't have much to add except congratulations to Ian for his mostly solo work on this. Having D "standardised" in this fashion within the GNU project can do nothing but benefit both D and GNU.

Re: D Language accepted for inclusion in GCC

#105
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.

If I'm not mistaken, Rust is being sold as a better C, not C++. Go is being marketed as a higher level language than C and Rust focused on developing network-aware concurrent applications to fill specific server needs. I may be wrong, but I'm not really sure that they target C++ or aim to replace it, unlike D. Perhaps that's the reason why both Rust and Go managed to gain so much traction and goodwill, because they a…

> Once the C++11 standardization process took off, D was pushed away into irrelevance.

No doubt about it, many existing C++ users feel this way. I've read the same comment many times. Most programmers, however, are not C++ programmers, and they are not looking for a better C++. They are looking for the best programming language for their needs (which means in most cases they won't go anywhere near C++). Your comment about D being irrelevant doesn't make much sense.

Re: D Language accepted for inclusion in GCC

#106
post #19

Earlier quoted context omitted.

D seems like a more useful Rust, or is that completely wrong?

They are very different languages. Rust was designed to be GC-free and memory safe. D, on the other hand, has GC and is memory unsafe by default.

Call me wrong if I misunderstood, but isn't reference counting also kind of GC?

Re: D Language accepted for inclusion in GCC

#107
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.

If I'm not mistaken, Rust is being sold as a better C, not C++. Go is being marketed as a higher level language than C and Rust focused on developing network-aware concurrent applications to fill specific server needs. I may be wrong, but I'm not really sure that they target C++ or aim to replace it, unlike D. Perhaps that's the reason why both Rust and Go managed to gain so much traction and goodwill, because they a…

> I'm not really sure that they target C++ or aim to replace it, unlike D.

The evolution of both Go's and Rust's strategies as "replacement" languages is actually pretty interesting.

While Go's official marketing no longer calls it a systems language, the use of that phrase when Go was originally released does indicate that that they envisioned Go to be a "better C" in a sense (perhaps specifically in the sense of being used for userspace "system" utilities in the same vein as the Rob Pike's C-like Alef on Plan 9). At the same time, much of the public rationale given for Go was obviously to avoid the pitfalls of using C++ at Google-like scales (e.g. an aversion to junior-dev footguns and a fanatical focus on fast compilation), which implies that they saw some potential for replacing C++, though they later acknowledged that very little of Go's growth appeared to be coming from C++ programmers (see https://commandcenter.blogspot.com/2012/06/less-is-exponenti... : "Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.").

Meanwhile, given that Mozilla intended to write a browser engine in Rust, old versions of Rust absolutely intended to replace C++. Like D and Go, ancient pre-0.1 Rust was willing to impose a runtime by default in order to guarantee memory safety (originally intending for both green threads and a garbage collector to be baked into the language), until years of experimentation proved that its static checks were capable of providing memory safety without a runtime, which is the pivotal moment in Rust history (actually a series of pivotal moments, but let me be romantic). Nowadays, rather than market itself as a C++ replacement exclusively, Rust tends to position itself outside of the traditional spectrum of languages as simply a zero-overhead memory-safe systems language. While it's still true Rust competes with C++, is inspired by C++, and can be used to replace C++ (e.g. its usage at Dropbox and in Firefox), Rust also intends to compete directly with C, e.g. for system utilities (e.g. ripgrep), reusable low-level libraries (e.g. librsvg), and extending high-level languages (e.g. Helix).

Re: D Language accepted for inclusion in GCC

#108
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

I am indeed proud that Iain is a member of our core D dev team! We're very fortunate.

Re: D Language accepted for inclusion in GCC

#109
post #19

Earlier quoted context omitted.

They are very different languages. Rust was designed to be GC-free and memory safe. D, on the other hand, has GC and is memory unsafe by default.

Call me wrong if I misunderstood, but isn't reference counting also kind of GC?

Rust doesn't use reference counting (until you want to use it)

Re: D Language accepted for inclusion in GCC

#110
post #90
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

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.

> D has not managed to die when it had so many chances to

One interesting thing about D is that we don't have to answer to anybody, so nobody can kill D other than us. We just keep steadily pushing forward regardless.

Post reply on HN