Random Fact: I can't help but smile when I read that D's "STL" is called Phobos because of my Doom 2 nostalgia :) Have a nice day, everyone o/
D's runtime is called Phobos because the language was originally named Mars.
Using D to Create the World’s Fastest File System
111–120 of 167 posts
Re: Using D to Create the World’s Fastest File System
#112I discovered D is a secret weapon at several companies, but not all of them want to make it widely known...
why is it in a company's best interest to not evangelize the publicly-available tools it uses? Microsoft/Amazon/Google are paying $$$ to increase availability of AI/machine learning education, because they want a knowledge pool to hire from. Wouldn't this be the same with languages?
Two have told me they did so because D enabled them to write faster code than their competitors, and they were in a line of business where faster code meant making more money.
One reason D code is faster is array slicing, where you can refer to a subsection of an array. This pays off for things like strings. Consider the string:
s = "/root/me/file.ext";
name = s[9 .. 13];
(A slice is equivalent to a (length, pointer) pair.)
Re: Using D to Create the World’s Fastest File System
#113Earlier quoted context omitted.
D had a closed source reference compiler for a long time, and didn't have any major backers. Rust had Mozilla backing early, and was fully open and transparent in terms of community feedback, and wasn't just making a language that had high level features, but was pioneering a new category of language that added tons of safety guarantees at compile time by default using a new paradigm of enforcing borrowing and owners…
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).
Re: Using D to Create the World’s Fastest File System
#114Earlier quoted context omitted.
The main reason the way I see it is that a lot of people who still use C and C++ need maximum speed, and D is only memory-safe with its garbage collector enabled. This affects latency and adds overhead. For many cases using a garbage collector is fine, but D was trying to target video games and other spaces where the GC was not acceptable. So D allows you to turn the GC off, but then it's just a vastly less-mature C+…
> D is only memory-safe with its garbage collector enabled. This is technically correct, but not pragmatically correct. D doesn't have every memory unsafe operation plugged, but it's pretty darned close, and does have the major ones covered (like array bounds checking, alternatives to pointers, RAII, etc.). > library support D has excellent library support.
> (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.
Re: Using D to Create the World’s Fastest File System
#115Earlier quoted context omitted.
that's just nitpicking. I bet you can find equally ugly examples in the other 2 languages. My point is that "standard" code is infinitely more readable than either c++ or rust.
> My point is that "standard" code is infinitely more readable than either c++ or rust. Still I'm struggling to see any code that is significantly more readable because of D's design decisions , or details on what makes D more readable than $lang (especially compared to modern C++/Rust that you seem to despise so much).
1. Template syntax. For example, a struct template in D is:
struct S(T) { ... }
T func(T)(T t) { ... }
3. Terser declarations:
ulong x;
unsigned long long x;
5. Nested functions mean they can be nestled close to where they are used rather than much further away in the file.
6. None of that awful
#ifndef __INCLUDED_FOO_H
#define __INCLUDED_FOO_H
...
#endifRe: Using D to Create the World’s Fastest File System
#116Earlier quoted context omitted.
> D is only memory-safe with its garbage collector enabled. This is technically correct, but not pragmatically correct. D doesn't have every memory unsafe operation plugged, but it's pretty darned close, and does have the major ones covered (like array bounds checking, alternatives to pointers, RAII, etc.). > library support D has excellent library support.
> (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.
Re: Using D to Create the World’s Fastest File System
#117Earlier quoted context omitted.
The main reason the way I see it is that a lot of people who still use C and C++ need maximum speed, and D is only memory-safe with its garbage collector enabled. This affects latency and adds overhead. For many cases using a garbage collector is fine, but D was trying to target video games and other spaces where the GC was not acceptable. So D allows you to turn the GC off, but then it's just a vastly less-mature C+…
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 happens. They are a non-predictable, non-consistent load.
If you're not working on a problem that is a sustained, consistent workload that needs sustained, consistent result generation then no, you probably won't see the same GC problems. GCs work great when the work is bursty or when the work has no latency associated with it. There's an awful lot of programs that fit in that model. Games just aren't one of them.
Re: Using D to Create the World’s Fastest File System
#118I 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 timeframe.
Second, Rust comes with an opinionated build system and module system out of the box, while D just has a compiler, you need to figure out building yourself and use a separate package manager. This is something you would be very comfortable with if you're a C/C++ programmer, but not so if you're using pretty much any other mainstream language. These days it's expected that the language comes with a compiler, build system and package manager.
Third, Rust is more novel, thus more interesting. It's a new language combining new programming paradigms in a novel way. Go has channels and goroutines, Rust has the borrow checker and zero overhead compile-time memory safety. D has... it's trying to be a better C++. It's succeeding very well, but its features aren't exciting.
In conclusion, Rust has come out the gate with great marketing, with novel and interesting features not seen before in a system programming language, and with great tooling support for the current generation of developers who don't want to bother with learning arcane Makefiles (or CMakefiles as the case may be today). D is just a better C++ with the same friction to use as the language it's trying to replace, but without the top-notch tooling that exists for C++. Rust on the other hand also doesn't have tooling quite as good as C++, but it's not replacing C++ in existing projects, it's used for new projects.
One case where D significantly outpaces Rust is in its ability to interface with C++. This gives it a significant edge in being considered for use in C++ projects, and I would expect that there are many cases of mixed D and C++ usage among the D success stories. Rust's lack of C++-compatibility story (I will be interested to hear how Mozilla integrate it with their C++ code!) is really what's holding the language back for my use-cases. The C ABI may be the lingua franca of low-level code, but a significant amount of native code is written in C++ and I need to interface with it natively via the platform's dominant C++ ABI. D would really shine in mixed C++ projects, but it really needs a turnkey solution for intellisense integration, i.e. better tooling. It would also need seamless debugger integration, letting me trivially step through D, C++ and C code in a mixed setting, and letting me place breakpoints, watch memory, etc.
Re: Using D to Create the World’s Fastest File System
#119I discovered D is a secret weapon at several companies, but not all of them want to make it widely known...
>D is a secret weapon at several companies That used to be said about Python back in the day, before it became as widely known and used as it is now.
The difference being with Python you gained in prototyping speed but were losing (at least at the time) on execution speed, whereas in D you get rapid prototyping while keeping very high efficiency.