D 2.065 released with 396 fixes and improvements | Hacker News Reader

D 2.065 released with 396 fixes and improvements

dlang.org

48 pointsandralex36 comments

I've been hearing good things about the D community, but I've yet to see what makes it a better choice than Rust or Go. Anyone care to enlighten me?

It's more of an attempt to provide a better C++, whereas I'd frame Rust or Go as attempts to avoid the need for a C++.

D might be for you if you're heavily into C++ template metaprogramming and wish it was neater and more expressive and all around more powerful.

I would classify both D and Rust as modern languages for systems programming, for those developers that care about expressive languages with meta-programming capabilities and modern type systems.

Go is rather what Java 1.0 should have been, 20 years later.

> modern type systems

I would dispute the fact that the type system is the a big draw to D. Whilst it is an improvement on C++, it is still hampered by the fact that it is ultimately descended from the ALGOL lineage. Advanced type systems lie with the MLs and Haskell, languages that Rust's type system is inspired by. What D has over Rust however is its expressive template metaprogramming. Templates have their shortcomings, but they are still a powerful form of static code generation that can really empower library developers.

Sure, I wasn't putting one against the other, as I like both languages and feel both will appeal to different types of audiences anyway.

My main point was that they follow the school that you need expressive type systems, even if as you noted, each has different strengths.

And both, each with a different set of mechanisms, allow for some sort of compile meta-programming.

This!

In addition to some of the other good answers here, D is a good deal older than Rust and is, I believe, more stable and mature as a result. If you're looking for a production-ready C++ alternative now, rather than X months from now, it seems like D is probably a better choice than Rust.

That is a good point, though D2 is younger than Rust, no?

Fair point. Sounds like you probably know a lot more than me. Is D2 enough of an overhaul that I'm wrong about their relative stability and maturity?

I know nothing, just what I've heard/read. If you go off age alone, 2006 vs 2001 isn't too far off.

No, D2 was first released in 2007. It wasn't a completely new language written from scratch though. It was D1 with the addition of features that broke backward compatibility.

Compared to Go: D is not focused on writing servers, but a more general language with much more features. Templates, Meta Programming, etc makes it more complex and harder to learn. However, it also gives you a comprehensive toolbox for any programming task you encounter.

Compared to Rust, D is rock solid stable, relatively. Ok, seriously. Rust seems to specialize on low-level or high-performance code. D also allows for high-level easy programming (aka Java) due to its simpler type system, garbage collector. However, D does not sacrifice performance. I think Rust will find its niche more as a C replacement than a C++ replacement.

>> Goto jumps now cannot skip variable declarations

I'm surprised that D lang even has a goto statement.

Go has goto too.

goto (used judiciously and sparingly) is fine and easier to understand and reason about than other flow control mechanisms would be in many situations.

The whole battle against goto has lost a little of its original context. Most languages with goto these days – yes even C – prevent the crazy kinds of things you could do in Basic, for example.

goto is common in C and C++ code as a clean way to consolidate cleanup code without using exceptions. I imagine that's the main use case they wanted to preserve.

Still, though, goto is considered so harmful that it's inspiration for "considered harmful" phrasing. Apple's goto-related SSL vulnerability this week is a blatant, high-profile reminder of how harmful it is.

> Still, though, goto is considered so harmful that it's inspiration for "considered harmful" phrasing.

It gets tiring constantly hearing this. We discussed it in depth 18 days ago [0]. I'm going to copy and paste something I said then, as it's relevant to your post:

> Also, a minor rant here: Dijkstra's "Go To Statement Considered Harmful" is often mentioned, sometime wordlessly, when goto is brought up, but it seems many of those people misunderstood what was actually being argued. Although he mentions being "convinced that the go to statement should be abolished from all 'higher level' programming languages," his main gripe was that the "unbridled use of the go to statement has an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress." He felt it was "as it stands is just too primitive; it is too much an invitation to make a mess of one's program." So, as others have pointed out already, his main issue was with goto being used in a way that resulted in unstructured, hard to understand programs.

[0] https://news.ycombinator.com/item?id=7191201

Edit: The original paper [1] is so short, it might as well be required reading before people bring up goto near any mention of "considered harmful".

[1] http://www.u.arizona.edu/~rubinson/copyright_violations/Go_T...

Apple's goto-related SSL vulnerability this week is a blatant, high-profile reminder of how harmful unbraced conditionals are. The same bug could have happened with two return statements in a row.

Amen.

Replace the "goto" with "Throw", "break", or "return", or any other construct, and you'd come up with the same problem.

I'm really thankful Rust does away with them. Static analysis can catch these things, but it should be prevented in the grammar from the start.

I'm not sure, I get your point: Rust has return..

I meant re. unbraced conditionals.

  goto cleanup;
  /* ... */
  cleanup: foo();

... is perfectly idiomatic C. It was the brace style that was the real stinker there.

Steve McConnell, in Code Complete, said in 1993: "These articles contain the whole goto debate. It erupts from time to time in most workplaces, textbooks, and magazines, but you won't hear anything that wasn't fully explored 20 years ago."

Thankfully he's got the whole section on his site. http://www.stevemcconnell.com/ccgoto.htm

> goto is common in C and C++ code as a clean way to consolidate cleanup code without using exceptions.

Most of the reason for this is the lack of higher level language constructs (e.g. `finally`). Keeping goto around for cleanup reminds of me of performing demolition with a nuclear bomb.

Goto is also very useful for machine-generated state machines, like Ragel or yacc parsers. I'd guess this is the only reason Go has goto, because it has "defer" for cleanup, which is functionally equivalent to "finally".

C++ has strong opinions on why it is lacking finally [0], and D has both try...catch...finally, and scope statements e.g. scope(exit).

Personally, I'm not sold that this is enough to argue for the removal of goto. I don't think goto-cleanup is the only sane use case of goto.

[0] http://www.stroustrup.com/bs_faq2.html#finally

Common in C.

C++ should focus on RAII destructors, such as std::lock_guard. I can't think of a legitimate time to use "goto" in C++, unless you were forced to emulate C for some reason.

It can be useful in deeply nested loops. One can certainly argue about the wisdom of deeply nested loops whose complexity requires a goto statement, but sometimes you just need to pop out of a loop to somewhere in a higher loop and goto solves that problem effectively.

Fair point. IIRC, Java and C# allow "break" statements to have a label associated with them specifically for this case. C++ "break" statements are all implicit.

So a goto is the only thing that can solve this problem.

Are there any plans to cut a new version of Andrei's book at some point? I keep meaning to find some time to work thorugh it, but it's getting quite out of date (Was current with 2.010 or something, I think)

I don't think the language has really changed enough to warrant a new version of The D Programming Language[1]. I highly recommend reading Andrei's book even for people who have no intention of actually using D. It's just a really good read for anyone that has even the slightest interest in programming language design because its filled with the rationale behind every design decision and Andrei is a good writer.

I'm doing a technical review of an upcoming book on D that I believe should be coming out the latter half of this year.

1. Jonathan Davis' list of changes since TDPL came out: http://forum.dlang.org/post/mailman.647.1327135415.16222.dig...

I think that link rather proves rather than disproves my point...the erratta list is almost one per page, and the mailing list post you linked to is from over 2 years ago.

A new run to fix mistakes would be nice but I don't think the publisher would jump at that since there isn't much motivation for current owners of the book to buy a version that is largely the same but with typos and other mistakes fixed.

The book is running out of stock. I am working on a third printing that fixes all errata.

Reply on news.ycombinator.com