5 ms·

Author here. Fire questions away!

by dukc 4y ago

avrionov 4y ago
What do you think prevents D to become more popular? It seems Rust and Go captured some of the mind share of D.
- metadat 4y ago
  Why isn't D more popular? (2014) https://news.ycombinator.com/item?id=7692230 https://news.ycombinator.com/item?id=7692230 (25 points, 16 comments)
- dukc 4y ago
  The short answer is, I really don't know. There are lots of speculation about that around. The only confident opinion I have is that good does not mean popular and vice-versa. But since you asked, I think I should make my guess. I think people tend to use what life brings them to. Most will not voluntarily go hunting for the best language the Internet has to offer for them. So the languages become popular by forcing people to learn them, by having them to use them at their jobs or implementing important APIs in them. This means that what the project managers of big organisations have enthusiasm or business reasons to push tends to end up popular, not what is preferred by the common programmer. D is largely a free-time volunteer effort AFAIK so it does not get as much corporate influence than it would get if it were an academic or commercial effort. But again, that is just a gut guess, no research to back this up.
  - mattarm 4y ago
    I think your second paragraph rings true. I also think there is a cost to using a non-mainstream technology that is often overlooked or under-estimated. I also think the benefits of non-mainstream languages are often over-stated. In other words, when you really look at the details the cool/niche languages do often have notable drawbacks. I suspect that for most organizations the pro/con or cost/benefit comparisons of C++ vs. D don't often come out in D's favor and never did. In the early days D chose to use GC which today, and for the past 30 years I have done C++ work professionally, has always been a dis-qualifier (mainly because of the extra memory overhead involved as well as the GC pauses). I have always looked at D with some interest, but never come close to formulating an argument that I could take to my company and suggest we start using D where we currently use C++. C++ almost uncompromisingly holds true to its backwards compatibility goals with C and the early versions of itself. C++ also almost always holds true to its "zero overhead abstraction" goals. D chose GC and replaced its standard library at one point. It is an interesting language for sure, but I think there are some things C++ has done better, from a practical use point of view, at least for the use cases where its use is still justified today, by being a more conservatively designed language.
    - mhh__ 4y ago
      The ironic thing is that the GC is one of the biggest productivity boosts available to a programmer. C++ likes to prattle on about zero cost abstractions but the cost is nearly always to the programmer - and even then D does a lot of the zero cost concepts like templates objectively better than C++: Write a struct with N members in C++ (e.g. for autodiff), you're looking at a page full of recursive templates and SFINAE. With D it's orders of magnitude less code because it was specifically designed to avoid this kind of nonsense that C++ has conditioned people to think is worthwhile.
- dzaima 4y ago
  My guess (as someone who hasn't used D) is that it looks/feels too much like C for people who want a better Java/C#/etc, and too much like Java for people looking for a better C, resting in the middle, not really being appealing for either use-case. GC makes it look like you won't do low-level things (e.g. pointer tagging or very-hand-optimized hot loops which might need to temporarily discard any and all safety), and being called a "systems language" makes it look like not very high-level either. Emphasis on "looks like" - not many will get to the point of actually looking for the options (especially when in a more opinionated language you don't even need to, as there either is an obvious way, or there's none). Rust managed to stay distant enough from Java-likes (mostly due to manual memory management), and Go is pretty distant from C all things considered (but I'm not too sure why it's so popular. Probably more just being backed by Google?)
  - mhh__ 4y ago
    > GC makes it look like you won't do low-level things Maybe this is true, I don't know, but to be clear other than the C runtime the language can be entirely implemented in D. You can do all these tricks and patterns easily and D and even have the compiler generate them for you (e.g. build your own loop unroller using metaprogramming if needs be), but I think people don't believe it to be true because of aesthetics.
- msla 4y ago
  Most languages never become popular. D is doing pretty well by becoming as popular as it has.
oconnor663 4y ago
Novice question about D: From my brief reading, it looks like appending to a slice in D avoids the "invalidate all references into the old allocation" problem in a similar way to how Go does it, by having the GC keep the old allocations alive as long as there are references into them. Is that right? How does that interact with optional garbage collection? Is there anything like C++'s std::vector or Rust's Vec that D programmers reach for when the GC is off?
- mhh__ 4y ago
  Not really. It's basically the holy grail for any future lifetime proposals for D. The GCC static analyzer is actually clever enough to spot these types of bugs (memory ones anyway, not database handles) but this doesn't scale.
- dukc 4y ago
  Yes, that is correct. There are all kinds of gc-less containers implemented for D, including the standard library std.container.array that is much like C++ std::vector. The downside of those is that they are not entirely memory safe. EDIT: Even slices do not mandate using the GC. The GC will only collect arrays registered to it in the first place. If the slice was malloced, it is not registered and thus won't be collected. The built-in ~ operator allocates the new array with the GC though, so you have do something custom to concatenate slices in GC-free code.
Smaug123 4y ago
"int* can point to the null address, but this is generally not a memory safety problem because the null address is protected by the operating system. Any attempt to dereference it would crash the program before any memory corruption can happen." This is the most cursed definition of "memory safe" I have ever seen. I think the article would benefit from a link to https://dlang.org/spec/memory-safe-d.html https://dlang.org/spec/memory-safe-d.html explaining explicitly that this is actually what you intended to write, because it made me do a double-take and a Google when I read it.
- verdagon 4y ago
  Mind explaining why it's a bad thing to rely on the OS's built-in protections around nulls? I'm familiar with a few arguments w.r.t. large structs and arrays running past the protected pages, but they seem pretty trivially solvable. Would love to hear why it's a cursed definition.
  - blep_ 4y ago
    Most definitions of memory safety include not crashing.
    - verdagon 4y ago
      What about bounds checking on array access, like most memory safe languages?
    - WalterBright 4y ago
      Having the program exit when a memory safety fault is detected is entirely safe.
    - dukc 4y ago
      Nope. Memory safety means no undefined behaviour. Crashing is defined behaviour. Indeed, at least in the D philosophy it is better to crash than to just do something and continue when a bug is detected. If that were not the case, assertions in released code would be total humbug. Now, detecting such errors statically at compile time is still valuable where it is practical. But it's common knowledge that no language guarantees no bugs. It follows that a complete "no crashing" guarantee is not even desirable, let alone part of a memory safety guarantee.
shadowofneptune 4y ago
What is the quality of support for these rules at the moment in external tools such as linters?
- dukc 4y ago
  I'm personally kind of anarchic, because I use hardly any tools. Text editor and terminal, that's how I program. The compiler is my linter. So I don't know.
  - dukc 4y ago
    Used the wrong word. Meant "archaic", not "anarchic". Side note, D has source code tools, this being probably the most famous one: https://github.com/dlang-community/D-Scanner https://github.com/dlang-community/D-Scanner . It's just that I don't use them myself.
- mhh__ 4y ago
  The rules are enforced by the compiler not a linter. Linting in a way that requires semantic analysis is not well trodden ground in D tooling. deadalnix and myself are aiming to rectify this somewhat by ramping up work on sdc, which is basically a D frontend done right.
- WalterBright 4y ago
  The idea with D is to not require a linter!

Author here. Fire questions away!

by dukc 4y ago

Author here. Fire questions away!

avrionov 4y ago

What do you think prevents D to become more popular? It seems Rust and Go captured some of the mind share of D.

metadat 4y ago
Why isn't D more popular? (2014) https://news.ycombinator.com/item?id=7692230 https://news.ycombinator.com/item?id=7692230 (25 points, 16 comments)
dukc 4y ago
The short answer is, I really don't know. There are lots of speculation about that around. The only confident opinion I have is that good does not mean popular and vice-versa. But since you asked, I think I should make my guess. I think people tend to use what life brings them to. Most will not voluntarily go hunting for the best language the Internet has to offer for them. So the languages become popular by forcing people to learn them, by having them to use them at their jobs or implementing important APIs in them. This means that what the project managers of big organisations have enthusiasm or business reasons to push tends to end up popular, not what is preferred by the common programmer. D is largely a free-time volunteer effort AFAIK so it does not get as much corporate influence than it would get if it were an academic or commercial effort. But again, that is just a gut guess, no research to back this up.
- mattarm 4y ago
  I think your second paragraph rings true. I also think there is a cost to using a non-mainstream technology that is often overlooked or under-estimated. I also think the benefits of non-mainstream languages are often over-stated. In other words, when you really look at the details the cool/niche languages do often have notable drawbacks. I suspect that for most organizations the pro/con or cost/benefit comparisons of C++ vs. D don't often come out in D's favor and never did. In the early days D chose to use GC which today, and for the past 30 years I have done C++ work professionally, has always been a dis-qualifier (mainly because of the extra memory overhead involved as well as the GC pauses). I have always looked at D with some interest, but never come close to formulating an argument that I could take to my company and suggest we start using D where we currently use C++. C++ almost uncompromisingly holds true to its backwards compatibility goals with C and the early versions of itself. C++ also almost always holds true to its "zero overhead abstraction" goals. D chose GC and replaced its standard library at one point. It is an interesting language for sure, but I think there are some things C++ has done better, from a practical use point of view, at least for the use cases where its use is still justified today, by being a more conservatively designed language.
  - mhh__ 4y ago
    The ironic thing is that the GC is one of the biggest productivity boosts available to a programmer. C++ likes to prattle on about zero cost abstractions but the cost is nearly always to the programmer - and even then D does a lot of the zero cost concepts like templates objectively better than C++: Write a struct with N members in C++ (e.g. for autodiff), you're looking at a page full of recursive templates and SFINAE. With D it's orders of magnitude less code because it was specifically designed to avoid this kind of nonsense that C++ has conditioned people to think is worthwhile.
dzaima 4y ago
My guess (as someone who hasn't used D) is that it looks/feels too much like C for people who want a better Java/C#/etc, and too much like Java for people looking for a better C, resting in the middle, not really being appealing for either use-case. GC makes it look like you won't do low-level things (e.g. pointer tagging or very-hand-optimized hot loops which might need to temporarily discard any and all safety), and being called a "systems language" makes it look like not very high-level either. Emphasis on "looks like" - not many will get to the point of actually looking for the options (especially when in a more opinionated language you don't even need to, as there either is an obvious way, or there's none). Rust managed to stay distant enough from Java-likes (mostly due to manual memory management), and Go is pretty distant from C all things considered (but I'm not too sure why it's so popular. Probably more just being backed by Google?)
- mhh__ 4y ago
  > GC makes it look like you won't do low-level things Maybe this is true, I don't know, but to be clear other than the C runtime the language can be entirely implemented in D. You can do all these tricks and patterns easily and D and even have the compiler generate them for you (e.g. build your own loop unroller using metaprogramming if needs be), but I think people don't believe it to be true because of aesthetics.
msla 4y ago
Most languages never become popular. D is doing pretty well by becoming as popular as it has.

oconnor663 4y ago

Novice question about D: From my brief reading, it looks like appending to a slice in D avoids the "invalidate all references into the old allocation" problem in a similar way to how Go does it, by having the GC keep the old allocations alive as long as there are references into them. Is that right? How does that interact with optional garbage collection? Is there anything like C++'s std::vector or Rust's Vec that D programmers reach for when the GC is off?

mhh__ 4y ago
Not really. It's basically the holy grail for any future lifetime proposals for D. The GCC static analyzer is actually clever enough to spot these types of bugs (memory ones anyway, not database handles) but this doesn't scale.
dukc 4y ago
Yes, that is correct. There are all kinds of gc-less containers implemented for D, including the standard library std.container.array that is much like C++ std::vector. The downside of those is that they are not entirely memory safe. EDIT: Even slices do not mandate using the GC. The GC will only collect arrays registered to it in the first place. If the slice was malloced, it is not registered and thus won't be collected. The built-in ~ operator allocates the new array with the GC though, so you have do something custom to concatenate slices in GC-free code.

Smaug123 4y ago

"int* can point to the null address, but this is generally not a memory safety problem because the null address is protected by the operating system. Any attempt to dereference it would crash the program before any memory corruption can happen." This is the most cursed definition of "memory safe" I have ever seen. I think the article would benefit from a link to https://dlang.org/spec/memory-safe-d.html https://dlang.org/spec/memory-safe-d.html explaining explicitly that this is actually what you intended to write, because it made me do a double-take and a Google when I read it.

verdagon 4y ago
Mind explaining why it's a bad thing to rely on the OS's built-in protections around nulls? I'm familiar with a few arguments w.r.t. large structs and arrays running past the protected pages, but they seem pretty trivially solvable. Would love to hear why it's a cursed definition.
- blep_ 4y ago
  Most definitions of memory safety include not crashing.
  - verdagon 4y ago
    What about bounds checking on array access, like most memory safe languages?
  - WalterBright 4y ago
    Having the program exit when a memory safety fault is detected is entirely safe.
  - dukc 4y ago
    Nope. Memory safety means no undefined behaviour. Crashing is defined behaviour. Indeed, at least in the D philosophy it is better to crash than to just do something and continue when a bug is detected. If that were not the case, assertions in released code would be total humbug. Now, detecting such errors statically at compile time is still valuable where it is practical. But it's common knowledge that no language guarantees no bugs. It follows that a complete "no crashing" guarantee is not even desirable, let alone part of a memory safety guarantee.

shadowofneptune 4y ago

What is the quality of support for these rules at the moment in external tools such as linters?

dukc 4y ago
I'm personally kind of anarchic, because I use hardly any tools. Text editor and terminal, that's how I program. The compiler is my linter. So I don't know.
- dukc 4y ago
  Used the wrong word. Meant "archaic", not "anarchic". Side note, D has source code tools, this being probably the most famous one: https://github.com/dlang-community/D-Scanner https://github.com/dlang-community/D-Scanner . It's just that I don't use them myself.
mhh__ 4y ago
The rules are enforced by the compiler not a linter. Linting in a way that requires semantic analysis is not well trodden ground in D tooling. deadalnix and myself are aiming to rectify this somewhat by ramping up work on sdc, which is basically a D frontend done right.
WalterBright 4y ago
The idea with D is to not require a linter!