10 ms·

I think the fundamental problem with D is much simpler than that, it's the technical context. D is a better C++, but it's not better enough to escape the gravit

by TillE 3y ago

I think the fundamental problem with D is much simpler than that, it's the technical context. D is a better C++, but it's not better enough to escape the gravitational pull of C++. Rust is sufficiently compelling, with its focus on memory safety.

LorenDB 3y ago
Meanwhile Rust is noncompelling due to its syntax. It made a bunch of weird design choices (like putting class methods in separate `impl` blocks) that have ruined my chances of trying to use it for any personal projects.
- Klonoar 3y ago
  That’s a subjective matter of taste.
  - LorenDB 3y ago
    Yes, but I think you'll find that many people tend to resist change, including drastic syntactic changes (as compared to how languages like D iterate on previous languages like C++).
    - lifthrasiir 3y ago
      Rust specifically changed its syntaxes to resemble C++. For example the turbofish syntax `::<T>` is actually a highly bad choice by its own, but was deemed more familiar to C++ users who are used to `<T>` (which was too ambiguous so had to be tweaked though). Even `return` was spelled `ret` back then!
    - nicoburns 3y ago
      Rust syntax isn’t really that novel. It’s not exactly like C, but most of its syntax is pulled from some popular language: some from C, some from JS, some from Python, some from ruby, etc.
      - aldanor 3y ago
        A lot more from ocaml than js/Python/ruby.
        littlestymaar 3y ago
        Lots of concepts come from Ocaml, but syntax-wise, Rust is closer to JS than to anything else.
- School-Cotton 3y ago
  That’s one of the most trivial imaginable reasons for choosing one language over another.
- johnbingus 3y ago
  I actually quite like that, because it makes it clear that the impl blocks aren't class methods, they're trait implementations. Maybe they could have chosen a better keyword, but having traits (aka typeclasses) instead of classes helps you mitigate the expression problem[1] and some other nasty things quite a bit. [1] https://en.m.wikipedia.org/wiki/Expression_problem https://en.m.wikipedia.org/wiki/Expression_problem
- xpressvideoz 3y ago
  There are a plethora of languages that allow implementing methods outside of a class block, including Java, Kotlin, Haskell, C#. And many of them are mainstream. Your argument seems weak.
- dureuill 3y ago
  You make it sound like Rust made these choices for the heck of it, whereas there are very good reasons why impl blocks are separate from the struct: 1. Make class methods open to extension. This allows adding methods from other contexts, including other privacy contexts. Sure you could have dedicated syntax like C#'s extension methods, but these were added after the fact. If starting your language from scratch, while have two distinct syntaxes, when one will do? 2. Allows to add methods that only exist for some combinations of generic parameters. For example you can have a generic `Foo<T>` class, and then define a method `from_bar` that only exists for `Foo<Bar>`. Again, impl blocks may not be the only solution to this, but it is a highly cohesive one. 3. Lastly this is more philosophical, but it decouples the data definition from the method definition. Not wanting to try Rust because its syntax is unfamiliar has to be the weakest reason, especially when the syntax has excellent reasons to be different.
- nextaccountic 3y ago
  impl blocks are actually more powerful than class methods because if you have a generic struct or enum MyType<T>, you can have a method for all MyType<T> or for just MyType<Something>
- tines 3y ago
  Putting class methods in separate impl blocks is actually objectively better; it allows you to define new methods on types that you didn't write, like typeclasses in Haskell.
  - tialaramex 3y ago
    Notice Rust actually forbids you from doing this to types you don't own. Rust's own standard library gets a pass. For example the [T] (a slice of T) generic type is a built-in, and the core library defines methods on that type, but in terms of sorting it only provides sort_unstable - an unstable sort, and the associated variants of that sort. Then Rust's alloc crate, which is optional, has a new impl block for [T] and it defines sort, a stable sort on this same type which is much faster than it might be otherwise because it uses a temporary buffer, hence it needs an allocator and can't live in core. You are not allowed to do this for other people's types. If I make a Goose in crate A, and then you try to write an impl block for A::Goose so that you can add a fly method to it, that won't work. Rust obviously could allow this, but it would invite chaos, so they don't. What you can do is invent a trait Flying and impl Flying for A::Goose
    - lf-non 3y ago
      Yeah I found it somewhat surprising too. Coming from kotlin I had expected this to be similar to extension methods but apparently not. I never fully understood the motivation behind this restriction.
      - tialaramex 3y ago
        Suppose I use Jim's birds crate, Sarah's noises crate and Hannah's shape crate. If Hannah is allowed to write impl birds::Goose { fn fudge(&mut self) { self.counter += 1; } } and Sarah is allowed to write impl birds::Goose { fn fudge(&mut self) { self.counter -= 1; } } ... Now what happens when I call fudge on a Goose? Does it increment the counter? Or decrement the counter? If instead the program is rejected because of the ambiguity, whose fault is the ambiguity? Sarah's fault? Hannah's fault? Jim's fault?
lifthrasiir 3y ago
I felt the opposite back when I was using D (specifically, D1). It was obvious that everything you can do in C++ can be done in D in so much easier way that it could have replaced C++ in a near future if done right. This is even true when we compare D1 with the current C++20, so I believe D did have a good chance that was wasted somehow.
- bsdpufferfish 3y ago
  To overcome something as entrenched as C++ it has to be 10x better. Even rust isn't there. Most of it's community isn't ex C and C++ experts, it's people getting into low-level programming for the first time, either from scripting language or pure functional.
  - lifthrasiir 3y ago
    Don't we consider a C/C++ replacement "successful" when it was able to capture enough share of prior C/C++ uses, not the entire share? I never thought C or C++ could be completely gone out of sight, even COBOL is technically alive today (on life support). To be clear, I meant that D could have been in the position of Rust today if done right.
    - bsdpufferfish 3y ago
      Yes, by that criteria C++ was successful over C. And C was successful over fortran. There are small communities that prefer the older stuff, but they were better enough to move the entire industry. D isn't, and neither is Rust. > I meant that D could have been in the position of Rust today if done right. My point was Rust is just a completely different audience. I suppose D could have sold itself as a better JavaScript. (Sorry for several rewrites.)
      - verall 3y ago
        I think you're correct for D, but for Rust, we'll see. It's a very slow moving industry. I do C++ work all day (embedded) and while there's no current plans to move to Rust (which means it won't happen within the next 3-5 years), I could see it occurring someday. We're finally (usually) allowed to use C++17. I had to use C++03 at times circa 2019 - we're finally done with that. It's _really_ slow moving.
fiddlerwoaroof 3y ago
Rust is a really frustrating language for me: I understand the safety it provides but find the pain of actually using it makes it uncompelling. Plus, the Rewrite it in Rust movement is very off-putting
- fiddlerwoaroof 3y ago
  As far as specific complaints go, async rust seems to be a trap: I’ve heard of several companies adopting it and then regretting the decision six months later because of the failure of that abstraction to adequately abstract.
  - anonymoushn 3y ago
    It's difficult to avoid, right? If you are writing a network server or client that manages a lot of connections, you can either use the popular async executor or you can stray far from the beaten path.
  - mplanchard 3y ago
    For more anecdata, I have been working professionally with async rust for three years and don’t understand why people complain so much about it. It solves the problem well, it provides predictable performance, and most of the time it’s straightforward to write and reason about.
- kstrauser 3y ago
  Rust pissed me off until I stopped fighting it. When I finally gave up and started doing things its way, it became a lot more fun. And `cargo clippy` is flat-out helpful for learning Rust’s idioms. While I’m not yet out to rewrite all the things in Rust, I understand the appeal of rebooting archaeological projects with a modern approach.
  - fiddlerwoaroof 3y ago
    The thing is, I just don’t want to write programs the way Rust wants me to. Among statically typed languages, Java is the closest to what I want to use but my true love is Common Lisp. With the arrival of Coalton, I can get the best of both worlds: a type system with nice properties for the rare program that would benefit from them and CL for the majority of programs.
dataflow 3y ago
I keep saying this and having the exact same argument with everyone every single time I mention it (and I'm sure here we'll go again), but D's fundamental problem was its GC. Its mere presence colors the code that uses it, and once your dependencies use the GC, you have no recourse. It's impossible to abstract away. I fail to see how such a language could ever substitute for C++.
- badsectoracula 3y ago
  According to the followup a week later[0] it seems OpenD is doubling down on GC: > One of the guiding principles of this fork is to embrace the GC as a successful design rather than to shun and avoid it. [...] I have harshly criticized @nogc in the past as putting a disproportionate burden on library authors while being the wrong answer to what can be a perfectly fair question. [0] https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.html https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.h...
  - petre 3y ago
    The GC works fine. Why waste energy to duplicate the functionality that requires it? Programmers who don't want the GC are already using C++ or Rust instead. The GC is one of those tools that makes programming in D productive. The lack of libraries and modern tooling is the part that ruins it. That's why you get software written in Go and Java instead of D. I'd love to use it for embedded work instead of C and C++, even in the current state. Embeded meaning 32bit MCUs running some kind of RTOS, not ARM SBCs powerful enough to run Linux. If not D, then maybe Zig. For this it needs to be able to link against and build upon existing C/C++ libraries.
    - badsectoracula 3y ago
      > Programmers who don't want the GC are already using C++ Sure, but this was in a response about D substituting C++.
    - hashmash 3y ago
      Unfortunately, the D garbage collector is a simple design that doesn't offer the performance and scalability of a modern collector. Someone switching over to D from Java/C#/Go might be surprised to see GC pauses reminiscent of 1998. Hopefully the maintainers of the D fork will address this.
foofie 3y ago
> I think the fundamental problem with D is much simpler than that, it's the technical context. D is a better C++, but it's not better enough to escape the gravitational pull of C++. Not quite. The problem with D is that it was a better C++ than C++98. In the meantime the C++ world woke up from it's freeze and the standardization process started addressing the requests from the C++ community. Consequently once C++11 was out and work picked up on following standard versions, D ceased to have a selling point.
p0nce 3y ago
Rust is sort-of a skin for C++11 though in terms of semantics, while new languages have GC to increase productivity.

by TillE 3y ago

LorenDB 3y ago

Meanwhile Rust is noncompelling due to its syntax. It made a bunch of weird design choices (like putting class methods in separate `impl` blocks) that have ruined my chances of trying to use it for any personal projects.

Klonoar 3y ago
That’s a subjective matter of taste.
- LorenDB 3y ago
  Yes, but I think you'll find that many people tend to resist change, including drastic syntactic changes (as compared to how languages like D iterate on previous languages like C++).
  - lifthrasiir 3y ago
    Rust specifically changed its syntaxes to resemble C++. For example the turbofish syntax `::<T>` is actually a highly bad choice by its own, but was deemed more familiar to C++ users who are used to `<T>` (which was too ambiguous so had to be tweaked though). Even `return` was spelled `ret` back then!
  - nicoburns 3y ago
    Rust syntax isn’t really that novel. It’s not exactly like C, but most of its syntax is pulled from some popular language: some from C, some from JS, some from Python, some from ruby, etc.
    - aldanor 3y ago
      A lot more from ocaml than js/Python/ruby.
      - littlestymaar 3y ago
        Lots of concepts come from Ocaml, but syntax-wise, Rust is closer to JS than to anything else.
School-Cotton 3y ago
That’s one of the most trivial imaginable reasons for choosing one language over another.
johnbingus 3y ago
I actually quite like that, because it makes it clear that the impl blocks aren't class methods, they're trait implementations. Maybe they could have chosen a better keyword, but having traits (aka typeclasses) instead of classes helps you mitigate the expression problem[1] and some other nasty things quite a bit. [1] https://en.m.wikipedia.org/wiki/Expression_problem https://en.m.wikipedia.org/wiki/Expression_problem
xpressvideoz 3y ago
There are a plethora of languages that allow implementing methods outside of a class block, including Java, Kotlin, Haskell, C#. And many of them are mainstream. Your argument seems weak.
dureuill 3y ago
You make it sound like Rust made these choices for the heck of it, whereas there are very good reasons why impl blocks are separate from the struct: 1. Make class methods open to extension. This allows adding methods from other contexts, including other privacy contexts. Sure you could have dedicated syntax like C#'s extension methods, but these were added after the fact. If starting your language from scratch, while have two distinct syntaxes, when one will do? 2. Allows to add methods that only exist for some combinations of generic parameters. For example you can have a generic `Foo<T>` class, and then define a method `from_bar` that only exists for `Foo<Bar>`. Again, impl blocks may not be the only solution to this, but it is a highly cohesive one. 3. Lastly this is more philosophical, but it decouples the data definition from the method definition. Not wanting to try Rust because its syntax is unfamiliar has to be the weakest reason, especially when the syntax has excellent reasons to be different.
nextaccountic 3y ago
impl blocks are actually more powerful than class methods because if you have a generic struct or enum MyType<T>, you can have a method for all MyType<T> or for just MyType<Something>
tines 3y ago
Putting class methods in separate impl blocks is actually objectively better; it allows you to define new methods on types that you didn't write, like typeclasses in Haskell.
- tialaramex 3y ago
  Notice Rust actually forbids you from doing this to types you don't own. Rust's own standard library gets a pass. For example the [T] (a slice of T) generic type is a built-in, and the core library defines methods on that type, but in terms of sorting it only provides sort_unstable - an unstable sort, and the associated variants of that sort. Then Rust's alloc crate, which is optional, has a new impl block for [T] and it defines sort, a stable sort on this same type which is much faster than it might be otherwise because it uses a temporary buffer, hence it needs an allocator and can't live in core. You are not allowed to do this for other people's types. If I make a Goose in crate A, and then you try to write an impl block for A::Goose so that you can add a fly method to it, that won't work. Rust obviously could allow this, but it would invite chaos, so they don't. What you can do is invent a trait Flying and impl Flying for A::Goose
  - lf-non 3y ago
    Yeah I found it somewhat surprising too. Coming from kotlin I had expected this to be similar to extension methods but apparently not. I never fully understood the motivation behind this restriction.
    - tialaramex 3y ago
      Suppose I use Jim's birds crate, Sarah's noises crate and Hannah's shape crate. If Hannah is allowed to write impl birds::Goose { fn fudge(&mut self) { self.counter += 1; } } and Sarah is allowed to write impl birds::Goose { fn fudge(&mut self) { self.counter -= 1; } } ... Now what happens when I call fudge on a Goose? Does it increment the counter? Or decrement the counter? If instead the program is rejected because of the ambiguity, whose fault is the ambiguity? Sarah's fault? Hannah's fault? Jim's fault?

lifthrasiir 3y ago

I felt the opposite back when I was using D (specifically, D1). It was obvious that everything you can do in C++ can be done in D in so much easier way that it could have replaced C++ in a near future if done right. This is even true when we compare D1 with the current C++20, so I believe D did have a good chance that was wasted somehow.

bsdpufferfish 3y ago
To overcome something as entrenched as C++ it has to be 10x better. Even rust isn't there. Most of it's community isn't ex C and C++ experts, it's people getting into low-level programming for the first time, either from scripting language or pure functional.
- lifthrasiir 3y ago
  Don't we consider a C/C++ replacement "successful" when it was able to capture enough share of prior C/C++ uses, not the entire share? I never thought C or C++ could be completely gone out of sight, even COBOL is technically alive today (on life support). To be clear, I meant that D could have been in the position of Rust today if done right.
  - bsdpufferfish 3y ago
    Yes, by that criteria C++ was successful over C. And C was successful over fortran. There are small communities that prefer the older stuff, but they were better enough to move the entire industry. D isn't, and neither is Rust. > I meant that D could have been in the position of Rust today if done right. My point was Rust is just a completely different audience. I suppose D could have sold itself as a better JavaScript. (Sorry for several rewrites.)
    - verall 3y ago
      I think you're correct for D, but for Rust, we'll see. It's a very slow moving industry. I do C++ work all day (embedded) and while there's no current plans to move to Rust (which means it won't happen within the next 3-5 years), I could see it occurring someday. We're finally (usually) allowed to use C++17. I had to use C++03 at times circa 2019 - we're finally done with that. It's _really_ slow moving.

fiddlerwoaroof 3y ago

Rust is a really frustrating language for me: I understand the safety it provides but find the pain of actually using it makes it uncompelling. Plus, the Rewrite it in Rust movement is very off-putting

fiddlerwoaroof 3y ago
As far as specific complaints go, async rust seems to be a trap: I’ve heard of several companies adopting it and then regretting the decision six months later because of the failure of that abstraction to adequately abstract.
- anonymoushn 3y ago
  It's difficult to avoid, right? If you are writing a network server or client that manages a lot of connections, you can either use the popular async executor or you can stray far from the beaten path.
- mplanchard 3y ago
  For more anecdata, I have been working professionally with async rust for three years and don’t understand why people complain so much about it. It solves the problem well, it provides predictable performance, and most of the time it’s straightforward to write and reason about.
kstrauser 3y ago
Rust pissed me off until I stopped fighting it. When I finally gave up and started doing things its way, it became a lot more fun. And `cargo clippy` is flat-out helpful for learning Rust’s idioms. While I’m not yet out to rewrite all the things in Rust, I understand the appeal of rebooting archaeological projects with a modern approach.
- fiddlerwoaroof 3y ago
  The thing is, I just don’t want to write programs the way Rust wants me to. Among statically typed languages, Java is the closest to what I want to use but my true love is Common Lisp. With the arrival of Coalton, I can get the best of both worlds: a type system with nice properties for the rare program that would benefit from them and CL for the majority of programs.

dataflow 3y ago

I keep saying this and having the exact same argument with everyone every single time I mention it (and I'm sure here we'll go again), but D's fundamental problem was its GC. Its mere presence colors the code that uses it, and once your dependencies use the GC, you have no recourse. It's impossible to abstract away. I fail to see how such a language could ever substitute for C++.

badsectoracula 3y ago
According to the followup a week later[0] it seems OpenD is doubling down on GC: > One of the guiding principles of this fork is to embrace the GC as a successful design rather than to shun and avoid it. [...] I have harshly criticized @nogc in the past as putting a disproportionate burden on library authors while being the wrong answer to what can be a perfectly fair question. [0] https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.html https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.h...
- petre 3y ago
  The GC works fine. Why waste energy to duplicate the functionality that requires it? Programmers who don't want the GC are already using C++ or Rust instead. The GC is one of those tools that makes programming in D productive. The lack of libraries and modern tooling is the part that ruins it. That's why you get software written in Go and Java instead of D. I'd love to use it for embedded work instead of C and C++, even in the current state. Embeded meaning 32bit MCUs running some kind of RTOS, not ARM SBCs powerful enough to run Linux. If not D, then maybe Zig. For this it needs to be able to link against and build upon existing C/C++ libraries.
  - badsectoracula 3y ago
    > Programmers who don't want the GC are already using C++ Sure, but this was in a response about D substituting C++.
  - hashmash 3y ago
    Unfortunately, the D garbage collector is a simple design that doesn't offer the performance and scalability of a modern collector. Someone switching over to D from Java/C#/Go might be surprised to see GC pauses reminiscent of 1998. Hopefully the maintainers of the D fork will address this.

foofie 3y ago

> I think the fundamental problem with D is much simpler than that, it's the technical context. D is a better C++, but it's not better enough to escape the gravitational pull of C++. Not quite. The problem with D is that it was a better C++ than C++98. In the meantime the C++ world woke up from it's freeze and the standardization process started addressing the requests from the C++ community. Consequently once C++11 was out and work picked up on following standard versions, D ceased to have a selling point.

p0nce 3y ago

Rust is sort-of a skin for C++11 though in terms of semantics, while new languages have GC to increase productivity.