Live data from Hacker News

D Language accepted for inclusion in GCC

gcc.gnu.org

141–150 of 235 posts

Re: D Language accepted for inclusion in GCC

#141
post #44

Earlier quoted context omitted.

https://dlang.org/spec/cpp_interface.html

> D understands how C++ function names are "mangled" and the correct C++ function call/return sequence. How does it work in practice ? C++ name mangling is not standardized and so every compiler can implement its own scheme. So does it mean there is a list of D compatible c++ compiler somewhere ? I have the feeling that if you are using some exotic proprietary c++ compiler it won't work well.

> C++ name mangling is not standardized and so every compiler can implement its own scheme.

That's right, and the D compiler deals with that by customizing the C++ mangling for every platform.

Re: D Language accepted for inclusion in GCC

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

Most people I know have not heard of D, but have definitely heard of Go, Swift and (less often, but still frequently) Rust. If in 16 years D has not achieved mass adoption, what is different now, when there are more competitors that offer better features?

It's a big world out there. Would you ever imagine that D would be taking market share from... Extended Pascal? But there's a naval architect who designs great big ships with a 500k sloc codebase he is exploring porting to D. Web guys get the attention but enterprise users are a much bigger world than just that.

If something is growing very quickly then saying it hasn't yet dethroned C, so it won't ever be significant seems to me to be a bit brittle thinking. Compound growth and the passage of time - thats what has been underway for some time now.

http://erdani.com/d/downloads.daily.png

Re: D Language accepted for inclusion in GCC

#143
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…

> D is arguably in the same bucket as Swift, and partly as Go. I don't think it's very useful to compare and contrast it against Rust.

It is easy to claim how things "arguably" are, but without providing any justification that is not a very meaningful statement to make.

D very much matches your definition of "low-level, zero-overhead (no GC) etc nature and powerful metaprogramming facilities" – the GC can be avoided easily enough. It can certainly claim to be a "better C++" in this sense. For instance, Weka.IO (a storage startup founded on D) heavily relies on D to offer exactly that, in order to implement a distributed file system with sub-100µs latency.

The fact that you can also write Python-esque code during prototyping (playing fast and loose with the GC, etc.) doesn't detract from the core identity of the language as a tool for systems programming with zero-cost abstractions.

Re: D Language accepted for inclusion in GCC

#144

Earlier quoted context omitted.

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…

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

Re: D Language accepted for inclusion in GCC

#145
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…

It's much more anti-fragile to have corporations who sponsor projects (as do we) than one or two key official sponsors. And it suits D's breadth too, because there's no single company that uses D for everything that's possible to do with it. Makes sense for Google to sponsor Go. Who is supposed to sponsor a language with versatility that encompasses C,C++ and Python and runs on the gamut of platforms. A single sponsor using D on Linux might direct energy away from Windows and embedded...

https://dlang.org/blog/2017/05/31/project-highlight-excel-d/

Re: D Language accepted for inclusion in GCC

#146
post #36

Earlier quoted context omitted.

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

I like Rust, but I hate with a passion the borrow system. So I was looking for an unsafe-by-default Rust and I found D, thanks to the suggestion of a kind HN user. I must admit that I love it!

Interesting. I like rust, and struggle with the borrow system, but what i'm looking for is a garbage-collected Rust!

Re: D Language accepted for inclusion in GCC

#147
post #132

Earlier quoted context omitted.

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

And more of a spiritual successor than an actual one.

You probably won't be writing kernels with it.

Re: D Language accepted for inclusion in GCC

#148
post #107

Earlier quoted context omitted.

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 be…

> 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

Rob Pike uses the phrase within the first 5 minutes or so of the very first presentation video announcing Go, and explicitly mentions that they mean "systems" in the sense of webservers and the like. Since then, Go being a systems language has endlessly (and often maliciously) been misrepresented, so under these circumstances, it's only understandable why this phrase was dropped, even though it was absolutely appropriate since its first use gave plenty of context.

Re: D Language accepted for inclusion in GCC

#149

Earlier quoted context omitted.

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

D is like Go if Go had actually been a "systems" programming language. Rust is difficult to compare to other stuff.

Go is still a systems programming language, in the original sense of how Rob Pike explained it in the introductory presentation video about Go from 2009.

Re: D Language accepted for inclusion in GCC

#150

Earlier quoted context omitted.

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…

> D is arguably in the same bucket as Swift, and partly as Go. I don't think it's very useful to compare and contrast it against Rust. It is easy to claim how things "arguably" are, but without providing any justification that is not a very meaningful statement to make. D very much matches your definition of "low-level, zero-overhead (no GC) etc nature and powerful metaprogramming facilities" – the GC can be avoided…

How is D's memory safety without the GC? How does it guarantee you don't use-after-free, de-ref nulls, buffer overflow, etc?
Post reply on HN