Hacker News Reader

Comment by grawprog | Hacker News Reader

I have to say, I like what I read there. I'm glad they're working more on c++ interoperability. I've ported some c++ code to D before, it wasn't not too bad, it wasn't a lot of code, but it would be great to be able to work directly with c++ libraries in D similarly to C libraries.

It always makes me sad D hasn't picked up more. Usually comments I see about D seem pretty ambivalent to dismissive. It's a great language and to me has always felt like the way C++ should have been.

It does seem to be growing in popularity. Even in the years I've been using it, the number of libraries and community resources has expanded exponentially and every day new code is being added to

https://code.dlang.org/

Not to mention dub is probably the most simple straightforward build system I've worked with.

View on HN

The main reason that D hasn't been picked up by anyone is mostly because it is an evolution of C++, not a revolution. Discarding an entire ecosystem for an evolution is not going to happen. Rust took a very different approach and just threw everything away. D looks and feels too much like C++, I would rather have hoped that effort would have been spent on making C++ better.

... and over the past decade-and-a-bit, C++ has been evolving itself quite nicely (IMHO), so the motivation for moving away from it has decreased. Also, now D probably has to "chase" some C++ developments.

The problem is that while modern C++17/20 are quite productive, we cannot get rid of C copy-paste compatibility and the errors of the past (see Python 3).

So either you work alone, in a small team that appreciates modern safe C++ (including Core guidelines), and enjoy C++, or you are faced to deal with all idiocrasies and unsafety issues from the past.

Well, it's not quite that dichotomous. It's quite possible to gradually modernize, or "beautify", an older-C-style codebase. And actually, having a transition path from older to newer code without a cliff is an advantage to switching languages.

I agree, however that modernization is only possible if the team actually buys into it, hence my remark about working alone or in a small team that embraces modern C++.

That's funny. I like to beautify old C++ codebases by gradually moving them to C. Code is so much easier to read already without implicit member accesses (this->). When going through large codebases, that must be one of the most frequent questions I'm asking myself, "is this a global, local, or member variable?".

Ah the beauty of use-after-free and memory corruption issues. /s

Try to find one here: https://github.com/jstimpfle/language

Not every project can be written 100% in this style, but the problem is very often programmers trying to mimick C++, e.g. doing object oriented fine-grained initialization/destruction stuff in C.

Will actually have a go at it.

As Google, Microsoft, Apple, Amazon have been reporting in multiple occasions, the problem goes beyond programmers trying to mimick C++.

To the point that future Android versions will require hardware memory tagging enabled on ARM devices.

Sure, I'm just saying that a lot of it is due to unsuitable approaches.

If you're actually going to look at it, I just want to make clear that I've never fuzzed it or anything, beyond running valgrind maybe twice (should be mentioned in the git log). And on the functional side, I don't even know what state this project is in. I think I lost interest in it when I needed to implement yet another way to encode x86-64 instructions, since having both floats and doubles is a requirement to run interesting things with OpenGL.

Let me know what problems you find!

1. Because C has no shadowing of global variables by member variables? 2. If your classes have so many members that it isn't clear whether a variable is a member or not, that's a class design problem. 3. C is a simplistic, almost-assembly-like, language. It's a reasonable choice for some tasks, not a reasonable choice for others. We're talking about languages with stronger abstraction capabilities.

> 2. If your classes have so many members that it isn't clear whether a variable is a member or not, that's a class design problem.

Now tell me why every OOP codebase I look at has this problem. ;-)

The reason is the second "O" in OOP. Trying to switch on the type of a thing, where every thing has only one type (ignoring inheritance which is another problem, not a solution), means that people will put all sorts of unrelated things in one place.

It might look like c++ but I can't say it 'feels' the same. The lack of header files in D immediately jumps to mind. D's module system is totatlly different from C++'s preprocessor. Ranges and slices are a big part in D programming that's a fair bit different than the way things are usually done in C++. Interfaces, Classes, structs are handled differently.

The similarities are more surface deep once you start learning more about the different features and tools D offers.

Not really, it doesn't feel like C++. D fixes many C++ annoyances, has a GC, doesn't have the annoying preprocessor, header files.

Walter Bright did try to make C++ better, remember that D came along after he wrote the Digital Mars C++ compiler.

C++ has also improved in the meantime.

I have programmed in both for years (commercially) and don't understand the comments about D being like C++. This is a night and day difference to me.

It is less about how it feels and more about how it looks.

And appearance really only changes when you hit templates. And with D you can't tell (as an outsider) so it just looks like the non templated C++.

Reply on news.ycombinator.com