121–130 of 167 posts
Earlier quoted context omitted.
> (like array bounds checking, alternatives to pointers, RAII, etc.). Yeah but C++ has all of that, too, as well as a vastly broader ecosystem in the space of non-GC'd, ultra-high-performance languages.
C++'s array bounds checking is there only if you use vector , not regular arrays.
fyi std::array also has bounds checking, you're not limited to vector to have that.
I would have liked to hear more about what exactly made D so great -- reading through it it's kind of vague. He mentions generics and finally getting LLVM support working as a target, and being able to use D at a high and low-level but I don't see anything here that's groundbreaking. Could someone who uses D Hate to be that guy, but if you could compare it with rust that would be double A++ good... I know the targets…
Here's a comparison with Nim. In my experience Nim is one of the fastest both in terms of execution and compile time. https://github.com/timotheecour/D_vs_nim
I would have liked to hear more about what exactly made D so great -- reading through it it's kind of vague. He mentions generics and finally getting LLVM support working as a target, and being able to use D at a high and low-level but I don't see anything here that's groundbreaking. Could someone who uses D Hate to be that guy, but if you could compare it with rust that would be double A++ good... I know the targets…
My experience, which of course is anecdotal, is that the advantage is it's easy to change the algorithms and data structures. I've maintained C and C++ code bases for decades, and I've found that the first algorithm I tried has stayed there in the code. It gets tweaked, optimized, refactored, but it's the same algorithm and data structure. With D, when I developed the Warp preprocessor, https://github.com/facebookarc…
Also for module access (as opposed to :: in c++). I feel like d has a lot (too much?) of syntax but this is one place where it manages to cut down on it a bit.
Earlier quoted context omitted.
C++'s array bounds checking is there only if you use vector , not regular arrays.
And D's bounds checking is only there if you don't use pointers or @trusted. fyi std::array also has bounds checking, you're not limited to vector to have that.
I have wondered for awhile now why Rust is getting all this attention of being "Like C but safe and cool!", but no one would mention D. I personally don't do systems programming because I'm not smart enough but the little bit I have done, I found D to be the most-natural feeling (even over Rust), and D has been around a lot longer. I suppose timing is everything for these kinds of things.
I can identify several traits that helped Rust be more marketable over D. First is that Rust is making tooling a central issue they're working on. Right now you can install VSCode and get a Rust plugin with a single click or get a VisualStudio plugin with a single click, and that gets you intellisense right away. I'm pretty sure that Rust's editor tooling has reached and surpassed D's in a comparatively tiny timefram…
There was a good blog post about this the other day: https://news.ycombinator.com/item?id=18588543
Earlier quoted context omitted.
D's compiler was never "closed source" if by that you mean "source not visible". It had a weird non-open source license for a long time, but the source has always been visible. The weird license did use to scare me away, but that's very much a thing of the past now and now it has a standard free license. https://news.ycombinator.com/item?id=14060846 I don't think D's features are any less exciting than Rust's, but Ru…
Source code being visible doesn't make it open source. It had a personal-use-only license, which isn't a valid OSSI license (which is what makes something open source).
I also freely granted that dmd's ad-hoc license wasn't open source despite having visible source.
I have wondered for awhile now why Rust is getting all this attention of being "Like C but safe and cool!", but no one would mention D. I personally don't do systems programming because I'm not smart enough but the little bit I have done, I found D to be the most-natural feeling (even over Rust), and D has been around a lot longer. I suppose timing is everything for these kinds of things.
D, from what I am aware of, did not offer any new abstractions. Rather, it was an attempt to do all of the existing abstractions in a better way. Which is laudable, but it can be hard to convince people to switch to a language when it offers only iterative improvements.
Earlier quoted context omitted.
Is the D GC actually that bad? Do we have benchmarks or something to prove that the GC means D is dead in the water? I always hear about this hypothetical danger of GC but my D usage hasn't found it and my D programs typically match or outperform my C++ programs. I mostly use it for numerical code, so maybe that's why I'm not feeling the pain of the GC? To address your final point, I find D vastly superior to C++. Im…
There is no such thing as a "good GC" in this context. Game engines go to great lengths to do things: 1) Have bounded memory usage 2) Have consistent frame times These goals are critical to maintain a consistent framerate on fixed-memory devices (aka, consoles). GCs, by their very nature, are not compatible with either of those goals. They need lots of spare memory to go fast, and they cause hiccups when collection h…
Earlier quoted context omitted.
Is the D GC actually that bad? Do we have benchmarks or something to prove that the GC means D is dead in the water? I always hear about this hypothetical danger of GC but my D usage hasn't found it and my D programs typically match or outperform my C++ programs. I mostly use it for numerical code, so maybe that's why I'm not feeling the pain of the GC? To address your final point, I find D vastly superior to C++. Im…
There is no such thing as a "good GC" in this context. Game engines go to great lengths to do things: 1) Have bounded memory usage 2) Have consistent frame times These goals are critical to maintain a consistent framerate on fixed-memory devices (aka, consoles). GCs, by their very nature, are not compatible with either of those goals. They need lots of spare memory to go fast, and they cause hiccups when collection h…
Earlier quoted context omitted.
There is no such thing as a "good GC" in this context. Game engines go to great lengths to do things: 1) Have bounded memory usage 2) Have consistent frame times These goals are critical to maintain a consistent framerate on fixed-memory devices (aka, consoles). GCs, by their very nature, are not compatible with either of those goals. They need lots of spare memory to go fast, and they cause hiccups when collection h…
And yet there are GCs in Unity and Unreal Engine, the most popular game engines of today.