4 ms·

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

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.
      - otabdeveloper4 3y ago
        > I could see it occurring someday "Someday" is on the order of decades here. By that time Rust will be a hoary legacy language with a list of warts longer than an ISO standard.
        dequan 3y ago
        Nonsense, WG21 is committed to ensuring C++ has more warts and sharp edges than any other language on the planet.
        otabdeveloper4 3y ago
        I don't agree. Rust very much wants to be a C++ alternative in all (I mean all) respects.
        dequan 3y ago
        Not really. The lack of fields in traits or a classical inheritance system is pretty strongly missed by some people coming from C++.
  - Shorel 3y ago
    > To be clear, I meant that D could have been in the position of Rust today if done right. Exactly. One language died arguing about a feature (Dlang), two different languages, one without it (Rust), another with it (Golang) proved that it was not as significant.
  - cxr 3y ago
    I wouldn't consider a C++ (or C) replacement PLₓ successful until the people working on big compiler toolchains—many of whom are committed alternative programming language advocates themselves (consider the origins of e.g. Swift and LLVM)—decide that, moving forward, those will be written in PLₓ rather than C++. (Note that the bar I'm establishing here is not merely to have a self-hosted compiler (see many toy compilers). I'm talking about a hypothetical future milestone where the software world's core infrastructure comprising LLVM/Clang and* GCC is written in the "replacement language", i.e. the compilers for a bunch of other (non-PLₓ) languages—including C and C++—are written in PLₓ as well. The backends, at least.) * "or"?
    - lifthrasiir 3y ago
      While I do hope that future, it is an unreasonably high bar because the main value of LLVM is that you don't have to make everything again to make your own PL implementation. For the same reason contemporary web browsers are unlikely to be fully rewritten in any other language unless they get completely displaced by newer browsers. (At least LLVM has a better chance of being replaced...)
      - cxr 3y ago
        > contemporary web browsers are unlikely to be fully rewritten in any other language Right. > it is an unreasonably high bar It's not an unreasonable standard. We're talking about replacement. If isn't replacing C++ for this use case, then it's not a replacement by definition.
        lifthrasiir 3y ago
        It's unreasonable in the sense that LLVM and a few others may survive even after pretty much everything else got replaced. We need to exempt some outliers with a very high sunk cost.
      - plorkyeran 3y ago
        A corollary of this is that a language probably needs to be able to interop with C++ to have any chance of being able to replace C++, so that the LLVMs and web browsers of the world can migrate incrementally. GCC was able to migrate from C to C++ because of this, and a migration from C++ to some other PL would need to work similarly.
- roca 3y ago
  There are a lot of high profile Rust adoption stories where the developers involved are C and C++ experts. E.g. Rust in the Linux kernel, Rust in the Windows kernel, Rust in Firefox, Rust in Android.
  - bsdpufferfish 3y ago
    I think the Rust in Firefox is probably the strongest in that list. Rust in Linux is just advocates trying to get adoption (not regular kernel contributors electing to use it).
    - dequan 3y ago
      That's not really accurate. Ojeda is a long time kernel contributor and so are many of the folks writing drivers. Maintainers of various subsystems are also particularly interested. Not everyone is of course, but hardly "just (Rust) advocates" like you suggest.
nordsieck 3y ago
> 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. Do you have an opinion on how the GC schism within D affected it competitively with regards to C/C++?
- lifthrasiir 3y ago
  While I don't know well about exact arguments for and against GC in that incident, I believe it's worthwhile to consider two cases when you want to avoid GC. One is the case where you shouldn't run GC because you have a very strict time limit and any GC pause is not desirable. The other is the case where GC pauses are discouraged but not the end of the world. D's `@nogc` only caters the former, which is much rarer than the later (i.e. hard realtime vs. soft realtime). So I think `@nogc` should have been more like an `@explicitgc`, where any allocation and thus GC pause should be marked in the syntax, but is not forbidden otherwise. But I do agree that something like `@nogc` was required.
  - Narishma 3y ago
    What about the situations where you don't want the memory overhead of the GC?
    - lifthrasiir 3y ago
      Again, the answer depends on whether you absolutely don't want that or just want to minimize that. I believe something like `@explicitgc` is enough annoyance to make sure that you are conscious about GC and memory allocation. If you need even more guarantee, you have to make sure that everything you transitively call is i) marked as `@explicitgc` and ii) has no GC call inside. Given enough demand you may have both `@nogc` and `@explicitgc` as well, but I think the hard guarantee is not something usually want. Maybe you wanted me to answer about some magical sauce that can conveniently avoid such issues, but I want to make a point that there is no such thing. In fact, Rust is praised for its strictness about memory safety, but that owes much to the existence of `panic`, and you know what? What I've described earlier equally applies to the `panic` behavior in Rust. You can not avoid panicking in Rust, though you can avoid panicking as much as possible and make `panic` immediately fail to avoid any further overhead, so you are liable for any panicking in your code. In the same way, if you really don't want to touch GC you are in the minority and should be served well with a placeholder GC that always fails. Anything beyond that is not something you can't expect from mainstream programming in the near future.

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.
    - otabdeveloper4 3y ago
      > I could see it occurring someday "Someday" is on the order of decades here. By that time Rust will be a hoary legacy language with a list of warts longer than an ISO standard.
      - dequan 3y ago
        Nonsense, WG21 is committed to ensuring C++ has more warts and sharp edges than any other language on the planet.
        otabdeveloper4 3y ago
        I don't agree. Rust very much wants to be a C++ alternative in all (I mean all) respects.
        dequan 3y ago
        Not really. The lack of fields in traits or a classical inheritance system is pretty strongly missed by some people coming from C++.
- Shorel 3y ago
  > To be clear, I meant that D could have been in the position of Rust today if done right. Exactly. One language died arguing about a feature (Dlang), two different languages, one without it (Rust), another with it (Golang) proved that it was not as significant.
- cxr 3y ago
  I wouldn't consider a C++ (or C) replacement PLₓ successful until the people working on big compiler toolchains—many of whom are committed alternative programming language advocates themselves (consider the origins of e.g. Swift and LLVM)—decide that, moving forward, those will be written in PLₓ rather than C++. (Note that the bar I'm establishing here is not merely to have a self-hosted compiler (see many toy compilers). I'm talking about a hypothetical future milestone where the software world's core infrastructure comprising LLVM/Clang and* GCC is written in the "replacement language", i.e. the compilers for a bunch of other (non-PLₓ) languages—including C and C++—are written in PLₓ as well. The backends, at least.) * "or"?
  - lifthrasiir 3y ago
    While I do hope that future, it is an unreasonably high bar because the main value of LLVM is that you don't have to make everything again to make your own PL implementation. For the same reason contemporary web browsers are unlikely to be fully rewritten in any other language unless they get completely displaced by newer browsers. (At least LLVM has a better chance of being replaced...)
    - cxr 3y ago
      > contemporary web browsers are unlikely to be fully rewritten in any other language Right. > it is an unreasonably high bar It's not an unreasonable standard. We're talking about replacement. If isn't replacing C++ for this use case, then it's not a replacement by definition.
      - lifthrasiir 3y ago
        It's unreasonable in the sense that LLVM and a few others may survive even after pretty much everything else got replaced. We need to exempt some outliers with a very high sunk cost.
    - plorkyeran 3y ago
      A corollary of this is that a language probably needs to be able to interop with C++ to have any chance of being able to replace C++, so that the LLVMs and web browsers of the world can migrate incrementally. GCC was able to migrate from C to C++ because of this, and a migration from C++ to some other PL would need to work similarly.
roca 3y ago
There are a lot of high profile Rust adoption stories where the developers involved are C and C++ experts. E.g. Rust in the Linux kernel, Rust in the Windows kernel, Rust in Firefox, Rust in Android.
- bsdpufferfish 3y ago
  I think the Rust in Firefox is probably the strongest in that list. Rust in Linux is just advocates trying to get adoption (not regular kernel contributors electing to use it).
  - dequan 3y ago
    That's not really accurate. Ojeda is a long time kernel contributor and so are many of the folks writing drivers. Maintainers of various subsystems are also particularly interested. Not everyone is of course, but hardly "just (Rust) advocates" like you suggest.

nordsieck 3y ago

> 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. Do you have an opinion on how the GC schism within D affected it competitively with regards to C/C++?

lifthrasiir 3y ago
While I don't know well about exact arguments for and against GC in that incident, I believe it's worthwhile to consider two cases when you want to avoid GC. One is the case where you shouldn't run GC because you have a very strict time limit and any GC pause is not desirable. The other is the case where GC pauses are discouraged but not the end of the world. D's `@nogc` only caters the former, which is much rarer than the later (i.e. hard realtime vs. soft realtime). So I think `@nogc` should have been more like an `@explicitgc`, where any allocation and thus GC pause should be marked in the syntax, but is not forbidden otherwise. But I do agree that something like `@nogc` was required.
- Narishma 3y ago
  What about the situations where you don't want the memory overhead of the GC?
  - lifthrasiir 3y ago
    Again, the answer depends on whether you absolutely don't want that or just want to minimize that. I believe something like `@explicitgc` is enough annoyance to make sure that you are conscious about GC and memory allocation. If you need even more guarantee, you have to make sure that everything you transitively call is i) marked as `@explicitgc` and ii) has no GC call inside. Given enough demand you may have both `@nogc` and `@explicitgc` as well, but I think the hard guarantee is not something usually want. Maybe you wanted me to answer about some magical sauce that can conveniently avoid such issues, but I want to make a point that there is no such thing. In fact, Rust is praised for its strictness about memory safety, but that owes much to the existence of `panic`, and you know what? What I've described earlier equally applies to the `panic` behavior in Rust. You can not avoid panicking in Rust, though you can avoid panicking as much as possible and make `panic` immediately fail to avoid any further overhead, so you are liable for any panicking in your code. In the same way, if you really don't want to touch GC you are in the minority and should be served well with a placeholder GC that always fails. Anything beyond that is not something you can't expect from mainstream programming in the near future.