3 ms·

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-a

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 actually offer entirely different takes on programming. D, on the other hand, tried to fix problems that existed only due to the lack of work developing C++ beyond the 98 standard. Once the C++11 standardization process took off, D was pushed away into irrelevance.

steveklabnik 9y ago
> 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."
- geezerjay 9y ago
  Thanks for taking the time to clear that up. Kudos.
jordigh 9y ago
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.
- arunc 9y ago
  Is sid0 still rewriting hg server with rust? Is there a chance to convince him to use D instead ;-)
bachmeier 9y ago
> 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.
- geezerjay 9y ago
  > and they are not looking for a better C++ And that's precisely why D fails. D was marketed as nothing more than C++'s successor, right down to the naming choice. No one is looking for a better C++, therefore no one bothers with D. Meanwhile, those who have to work with C++ keep their eyes in the C++ standardization process. Since D's inception, the C++ standardization committee already produced three standards which oddly enough do include stuff that is sought after by the C++ community.
  - kal31dic 9y ago
    D was marketed as 'Mars', but for some reason people insisted on calling it 'D' instead, and Walter relented and changed the name of the language. It's great that C++ is catching up. It's almost got static if, except not because it introduces a new scope. Maybe next time... The C++ programmers I know are attached to native code, but not exactly content with C++. Ethan Watson of Remedy Games (Quantum Break) said "we are an industry looking for salvation".
kibwen 9y ago
> 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-exponentially-more.html 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).
- treehau5 9y ago
  I would like to contact Go's "official marketing" department and tell them they have done a horrible job at marketing, because most of the lauding for go comes from developers I know that love getting work done with it! In any case, I will +1 you on coming from python and ruby, and add another major bucket go developers come from is node js.
jxub 9y ago
D may be a sort of "SpaceX" of languages, designed to improve the competition up to a point it's no longer needed, more or less like Scala did with Java. But even that is a huge success, maybe better than finishing C++ off.

steveklabnik 9y ago

> 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."

geezerjay 9y ago
Thanks for taking the time to clear that up. Kudos.

jordigh 9y ago

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.

arunc 9y ago
Is sid0 still rewriting hg server with rust? Is there a chance to convince him to use D instead ;-)

bachmeier 9y ago

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

geezerjay 9y ago
> and they are not looking for a better C++ And that's precisely why D fails. D was marketed as nothing more than C++'s successor, right down to the naming choice. No one is looking for a better C++, therefore no one bothers with D. Meanwhile, those who have to work with C++ keep their eyes in the C++ standardization process. Since D's inception, the C++ standardization committee already produced three standards which oddly enough do include stuff that is sought after by the C++ community.
- kal31dic 9y ago
  D was marketed as 'Mars', but for some reason people insisted on calling it 'D' instead, and Walter relented and changed the name of the language. It's great that C++ is catching up. It's almost got static if, except not because it introduces a new scope. Maybe next time... The C++ programmers I know are attached to native code, but not exactly content with C++. Ethan Watson of Remedy Games (Quantum Break) said "we are an industry looking for salvation".

kibwen 9y ago

> 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-exponentially-more.html 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).

treehau5 9y ago
I would like to contact Go's "official marketing" department and tell them they have done a horrible job at marketing, because most of the lauding for go comes from developers I know that love getting work done with it! In any case, I will +1 you on coming from python and ruby, and add another major bucket go developers come from is node js.

jxub 9y ago

D may be a sort of "SpaceX" of languages, designed to improve the competition up to a point it's no longer needed, more or less like Scala did with Java. But even that is a huge success, maybe better than finishing C++ off.