Live data from Hacker News

D Language accepted for inclusion in GCC

gcc.gnu.org

151–160 of 235 posts

Re: D Language accepted for inclusion in GCC

#151
post #80

Earlier quoted context omitted.

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

Just more pragmatic, I'd say. D isn't a "big agenda language" (to steal a line from Jonathan Blow). It's extremely multi-paradigm (some might argue to a fault). I think that's why you find people saying D is like C++ or D is like C# or D is like Go or D is like Rust. You get a little taste of everything using D. Want function programming and purity? Check. Want C style/low abstraction code? Check. Want extreme C++ me…

What's D's LINQ equivalent?

Re: D Language accepted for inclusion in GCC

#153

Earlier quoted context omitted.

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

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

Re: D Language accepted for inclusion in GCC

#154
post #132

Earlier quoted context omitted.

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.

No as Go has a GC. It's just supposed to be a fast server-side language without very complicated code. Go is mostly successful due to Google and filling a niche (fast, simple, concurrent, all thrown into a fat statically linked binary I think).

Re: D Language accepted for inclusion in GCC

#156
post #131

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…

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

I agree with your points. I do like to bring Nim up as it uses python like syntax with types and then transpiles to C. You get a fast and small native binary and can choose from 2 different GC or no GC. It has a small, but very active community.

Re: D Language accepted for inclusion in GCC

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

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

Thanks for the hard work Walter. Random question: I heard D has something like C#'s LINQ. Is that true?

Re: D Language accepted for inclusion in GCC

#159
post #83

Earlier quoted context omitted.

It is a clear alternative to C++. The GC is optional.

Is it? Last time I checked a few years ago there were huge caveats to allocation Objects on the stack (I forget what they were) so unless something's drastically changed this doesn't seem like an honest assessment.

If you want to allocate an object on the stack, then use std.conv : emplace and alloca. This(https://wiki.dlang.org/Memory_Management#Allocating_Class_In...) method also exists but is on the road to deprecation

Re: D Language accepted for inclusion in GCC

#160

Earlier quoted context omitted.

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

Great question! The answer is a bit more than a simple reply can do, so:

Pointers Gone Wild: Memory Safety and D http://dconf.org/2017/talks/bright.html

Post reply on HN