5 ms·

I used D for a while. It improves several things over C++, among them: - More powerful metaprogramming capabilities. - Better module and library system. - Ni

I used D for a while. It improves several things over C++, among them: - More powerful metaprogramming capabilities. - Better module and library system. - Nicer syntax. The problem IMO is it's just not enough to justify a total move from C++ -> D. The syntax of C++ can't really be fixed, but the other aspects can be improved without a new language. Furthermore, many of the other downsides of C++ are still present: - The complexity of the language, and then the sheer number of different ways of doing the same thing. - Some pretty dark corners in the way stdlib/language feature were implemented that seemed hard to ever fix. - The way behaviour is specified in the language is very tied to the underlying hardware: rather than explicitly describing behaviour in terms of an abstract machine, it works more in the way C++ is specified where we all know it operates on an abstract machine thanks to compiler optimizations, but the spec likes to pretend it doesn't... And then there are problems that are introduced by D, such as the fact that a safe subset exists, but depends on GC, so there's a weird split where no "safe code" can be used in contexts where GC is unsuitable. Contrast this to Rust, where: - There is a true step-change in bringing safe code to all contexts, not just those where GC can be used. - It's missing a lot of the complexity of C++. Rust is hard because it has concepts that are foreign to a lot of programmers, but the total number of features is low (compared to C++) so there are fewer surprising ways they can interact. - Rust is a suitable replacement for C, not just C++, because it's not just adding more features.

mhh__ 5y ago
The idea that Rust is suitable to replace C and D isn't is odd to me. It's really not hard to do + we (unlike some languages, not sure about rust) actually test on embedded targets via GCC.
- Diggsey 5y ago
  What I meant by this is: if you are starting a project today, and have to choose between C and C++, there are certain reasons why you might choose C over C++. Those same reasons would apply for choosing C over D. They might not apply for choosing C over Rust.
  - mhh__ 5y ago
    I can't think of a reason that would apply here. For me at least if I were on a toolchain so crap I had to use C you'd have to pay me a lot of money not to work on something else.
    - SLWW 5y ago
      All my embedded design work has been in C as i don't need all the extra cruft. Also anything i want to be very fast on limited hardware i also use C and C only. As for any hobby programming i do on the side, C is usually my goto choice, unless i want to be very esoteric.. following along the lines of: "The enemy of art is the absence of limitations."
      - mhh__ 5y ago
        I find that C actually gets in my way compared to D when I am writing code with limited resources. The end result is semantically the same but with D I can avoid macros, inline asm is easier etc.
        SLWW 5y ago
        while this makes all the sense in the world to even a seasoned C programmer... I've been doing it so long I could write macros in my sleep, and inline asm is a fun little exercise. Though i absolutely agree, especially with someone newer, that could be a major road block. Might want to learn D just to be more efficient (even though I will never abandon my first love completely)
  - stjohnswarts 5y ago
    Almost the only reason I would choose c over c++ for embedded would be if the c++ compiler was garbage for the platform or the team wouldn't allow it.
haolez 5y ago
Except that Rust compilers seem incredibly hard to implement, as opposed to C.
- echelon 5y ago
  I don't think minimal compiler complexity is a real requirement as much as safe and reliable software is. CPU fabs aren't easy, yet we're fine with that.
  - haolez 5y ago
    It matters for portability. I'm not saying it's the most important requirement, of course, but it's C strongest point.
    - Zababa 5y ago
      Do you need to build an entire compiler or "just" the backend/code generation to port something? Although "just" a code generation for Rust means building one for LLVM, which I'm sure is harder than some C compilers out there.
    - deleted 5y ago
      [deleted]
- maxpert 5y ago
  That is very true but absolutely fine because then some fine set of engineers can do the hard lifting parts and rest of the ecosystem can thrive on stable base that core establishes. That is how things work in most of industries, not everybody is writing a compiler (or even suitable for writing one!), but the complexity compilers remove lets you build more complex pieces of engineering.
- pas 5y ago
  To give some perspective: mrustc is written mostly by one person, in C++ and it caught up to 1.39.0 recently - meaning it can "compile" rustc itself (without any type safety validation) as opposed to arbitrary Rust code. Also C++ compilers are hard too. And optimizing C compilers are hard too...
eggy 5y ago
I am learning Rust and SPARK2014, and I would think SPARK2014/Ada would be a better fit for high-integrity software for verifiable, embedded software than Rust. This was the older article that stimulated me to look at Ada and then SPARK2014 again: https://www.embedded.com/spark-2014-why-i-am-backing-a-predictable-winner/ https://www.embedded.com/spark-2014-why-i-am-backing-a-predi... EDIT: Cool list of SPARK2014/Ada embedded projects: https://blog.adacore.com/tag/embedded%20development https://blog.adacore.com/tag/embedded%20development
- nicoburns 5y ago
  That's probably true for now. But only because there's no equivalent to SPARK for Rust yet. Rust + something like SPARK could be really amazing.
  - gavinray 5y ago
    There are some things that attempt to come close. Prusti by ETH Zurich is maybe the closest. https://github.com/viperproject/prusti-dev https://github.com/viperproject/prusti-dev https://www.pm.inf.ethz.ch/research/prusti.html https://www.pm.inf.ethz.ch/research/prusti.html extern crate prusti_contracts; use prusti_contracts::*; #[requires(something)] #[ensures(result >= a && result >= b)] #[ensures(result == a || result == b)] fn max(a: i32, b: i32) -> i32 { if a > b { a } else { b } } Ada seems like a fantastic language though, and the 202x edition brought some niceties to the language.
    - eggy 5y ago
      I am an Ada/SPARK novice, but on first look Prusti seems to deal with contracts, but I am not sure how much more of the Ada/SPARK system it may covergg. I used to dislike Ada and SPARK due to their verbosity, but after studying some of the embedded work in them, and what they bring to the table, I am no longer put off by that or syntax. I've seen Julia and even Elixir projects in areas that would better suit Ada/SPARK, but I think it is due to their popularity rather than applicability. But things like Elixir's Nerves platform is very interesting in bringing the BEAM to the embedded world, and I love Pluto notebooks for Julia, but for high-integrity software I think I'll try and leverage Ada/SPARK's capabilities and pedigree for now. I will look further into Prusti this weekend.
brianush1 5y ago
> such as the fact that a safe subset exists, but depends on GC, @safe works perfectly fine and exactly the same in @nogc code as in GC-enabled code.
- Diggsey 5y ago
  My mistake - SafeD was introduced since I stopped using D, so I was going off this article: https://dlang.org/articles/safed.html#safed-subset https://dlang.org/articles/safed.html#safed-subset > When you enter SafeD, you leave your pointers, unchecked casts and unions at the door. Memory management is provided to you courtesy of Garbage Collection. Does D provide the necessary tooling to be able to expose a safe API for something which needs to allocate memory, without needing a GC?
  - alphaglosined 5y ago
    You are stuck with dropping to @trusted and calling the appropriate allocator API. Following that you will want to check for null ext. to make it actually @safe in practice and not just typed as such.
  - zombinedev 5y ago
    https://github.com/atilaneves/automem https://github.com/atilaneves/automem
- PoignardAzur 5y ago
  That's a bit disingenuous. Memory allocations in D require either GC or non-local unsafe code. I'm aware that D has @live, a WIP attribute that mimics Rust semantics, but it's not remotely ready for production.
LAC-Tech 5y ago
D is easy to pick up, and has three really fast compilers. It feels like a very practical language. Rust in comparison feels much less practical - glacial compile times and byzantine rules about manging memory. It may be 'safer' but that's a moot point when I find it all so unintuitive that I'm not going to be able to make anything with it anyway. And I really question what these situations are where you can't have garbage collection in 2021. Hard real time systems, sure, but that's not what 99% of people are using rust for. Maybe people just like the challenge.
- whatshisface 5y ago
  >And I really question what these situations are where you can't have garbage collection in 2021. Game development, anything with a UI (GC pauses frustrate users), anything that needs high performance (scientific applications, data analysis), you name it. Ownership semantics have a side-benefit of automatic thread safety; something that is less important than memory safety (because many programs can work in one thread but almost no programs can work without allocation) but extremely valuable when needed.
  - nec4b 5y ago
    >Game development C# Unity, Lua Love 2D,... >anything with a UI (GC pauses frustrate users) Millions of C#, Java, Python, Javascript UI apps >anything that needs high performance (scientific applications, data analysis) Numpy, Julia,... Using non garbage collected languages for 99% of apps today is a waste of time, and i'm saying this as mostly an embedded developer.
    - whatshisface 5y ago
      You listed a bunch of engines written in C and C++.
      - maleldil 5y ago
        How does that matter? You said "game development", not "writing a game engine". You said "data analysis", not "writing linalg algorithms", in which case we'd all have to bow to Fortran anyway. Your argument also doesn't apply to GUI apps, anyway. C# and Java amount to a huge number of such apps, and they're self-hosted. GC languages are vastly more productive that manual-memory languages, and for the vast majority of users, that is worth the performance hit.

mhh__ 5y ago

The idea that Rust is suitable to replace C and D isn't is odd to me. It's really not hard to do + we (unlike some languages, not sure about rust) actually test on embedded targets via GCC.

Diggsey 5y ago
What I meant by this is: if you are starting a project today, and have to choose between C and C++, there are certain reasons why you might choose C over C++. Those same reasons would apply for choosing C over D. They might not apply for choosing C over Rust.
- mhh__ 5y ago
  I can't think of a reason that would apply here. For me at least if I were on a toolchain so crap I had to use C you'd have to pay me a lot of money not to work on something else.
  - SLWW 5y ago
    All my embedded design work has been in C as i don't need all the extra cruft. Also anything i want to be very fast on limited hardware i also use C and C only. As for any hobby programming i do on the side, C is usually my goto choice, unless i want to be very esoteric.. following along the lines of: "The enemy of art is the absence of limitations."
    - mhh__ 5y ago
      I find that C actually gets in my way compared to D when I am writing code with limited resources. The end result is semantically the same but with D I can avoid macros, inline asm is easier etc.
      - SLWW 5y ago
        while this makes all the sense in the world to even a seasoned C programmer... I've been doing it so long I could write macros in my sleep, and inline asm is a fun little exercise. Though i absolutely agree, especially with someone newer, that could be a major road block. Might want to learn D just to be more efficient (even though I will never abandon my first love completely)
- stjohnswarts 5y ago
  Almost the only reason I would choose c over c++ for embedded would be if the c++ compiler was garbage for the platform or the team wouldn't allow it.

haolez 5y ago

Except that Rust compilers seem incredibly hard to implement, as opposed to C.

echelon 5y ago
I don't think minimal compiler complexity is a real requirement as much as safe and reliable software is. CPU fabs aren't easy, yet we're fine with that.
- haolez 5y ago
  It matters for portability. I'm not saying it's the most important requirement, of course, but it's C strongest point.
  - Zababa 5y ago
    Do you need to build an entire compiler or "just" the backend/code generation to port something? Although "just" a code generation for Rust means building one for LLVM, which I'm sure is harder than some C compilers out there.
  - deleted 5y ago
    [deleted]
maxpert 5y ago
That is very true but absolutely fine because then some fine set of engineers can do the hard lifting parts and rest of the ecosystem can thrive on stable base that core establishes. That is how things work in most of industries, not everybody is writing a compiler (or even suitable for writing one!), but the complexity compilers remove lets you build more complex pieces of engineering.
pas 5y ago
To give some perspective: mrustc is written mostly by one person, in C++ and it caught up to 1.39.0 recently - meaning it can "compile" rustc itself (without any type safety validation) as opposed to arbitrary Rust code. Also C++ compilers are hard too. And optimizing C compilers are hard too...

eggy 5y ago

I am learning Rust and SPARK2014, and I would think SPARK2014/Ada would be a better fit for high-integrity software for verifiable, embedded software than Rust. This was the older article that stimulated me to look at Ada and then SPARK2014 again: https://www.embedded.com/spark-2014-why-i-am-backing-a-predictable-winner/ https://www.embedded.com/spark-2014-why-i-am-backing-a-predi... EDIT: Cool list of SPARK2014/Ada embedded projects: https://blog.adacore.com/tag/embedded%20development https://blog.adacore.com/tag/embedded%20development

nicoburns 5y ago
That's probably true for now. But only because there's no equivalent to SPARK for Rust yet. Rust + something like SPARK could be really amazing.
- gavinray 5y ago
  There are some things that attempt to come close. Prusti by ETH Zurich is maybe the closest. https://github.com/viperproject/prusti-dev https://github.com/viperproject/prusti-dev https://www.pm.inf.ethz.ch/research/prusti.html https://www.pm.inf.ethz.ch/research/prusti.html extern crate prusti_contracts; use prusti_contracts::*; #[requires(something)] #[ensures(result >= a && result >= b)] #[ensures(result == a || result == b)] fn max(a: i32, b: i32) -> i32 { if a > b { a } else { b } } Ada seems like a fantastic language though, and the 202x edition brought some niceties to the language.
  - eggy 5y ago
    I am an Ada/SPARK novice, but on first look Prusti seems to deal with contracts, but I am not sure how much more of the Ada/SPARK system it may covergg. I used to dislike Ada and SPARK due to their verbosity, but after studying some of the embedded work in them, and what they bring to the table, I am no longer put off by that or syntax. I've seen Julia and even Elixir projects in areas that would better suit Ada/SPARK, but I think it is due to their popularity rather than applicability. But things like Elixir's Nerves platform is very interesting in bringing the BEAM to the embedded world, and I love Pluto notebooks for Julia, but for high-integrity software I think I'll try and leverage Ada/SPARK's capabilities and pedigree for now. I will look further into Prusti this weekend.

brianush1 5y ago

> such as the fact that a safe subset exists, but depends on GC, @safe works perfectly fine and exactly the same in @nogc code as in GC-enabled code.

Diggsey 5y ago
My mistake - SafeD was introduced since I stopped using D, so I was going off this article: https://dlang.org/articles/safed.html#safed-subset https://dlang.org/articles/safed.html#safed-subset > When you enter SafeD, you leave your pointers, unchecked casts and unions at the door. Memory management is provided to you courtesy of Garbage Collection. Does D provide the necessary tooling to be able to expose a safe API for something which needs to allocate memory, without needing a GC?
- alphaglosined 5y ago
  You are stuck with dropping to @trusted and calling the appropriate allocator API. Following that you will want to check for null ext. to make it actually @safe in practice and not just typed as such.
- zombinedev 5y ago
  https://github.com/atilaneves/automem https://github.com/atilaneves/automem
PoignardAzur 5y ago
That's a bit disingenuous. Memory allocations in D require either GC or non-local unsafe code. I'm aware that D has @live, a WIP attribute that mimics Rust semantics, but it's not remotely ready for production.

LAC-Tech 5y ago

D is easy to pick up, and has three really fast compilers. It feels like a very practical language. Rust in comparison feels much less practical - glacial compile times and byzantine rules about manging memory. It may be 'safer' but that's a moot point when I find it all so unintuitive that I'm not going to be able to make anything with it anyway. And I really question what these situations are where you can't have garbage collection in 2021. Hard real time systems, sure, but that's not what 99% of people are using rust for. Maybe people just like the challenge.

whatshisface 5y ago
>And I really question what these situations are where you can't have garbage collection in 2021. Game development, anything with a UI (GC pauses frustrate users), anything that needs high performance (scientific applications, data analysis), you name it. Ownership semantics have a side-benefit of automatic thread safety; something that is less important than memory safety (because many programs can work in one thread but almost no programs can work without allocation) but extremely valuable when needed.
- nec4b 5y ago
  >Game development C# Unity, Lua Love 2D,... >anything with a UI (GC pauses frustrate users) Millions of C#, Java, Python, Javascript UI apps >anything that needs high performance (scientific applications, data analysis) Numpy, Julia,... Using non garbage collected languages for 99% of apps today is a waste of time, and i'm saying this as mostly an embedded developer.
  - whatshisface 5y ago
    You listed a bunch of engines written in C and C++.
    - maleldil 5y ago
      How does that matter? You said "game development", not "writing a game engine". You said "data analysis", not "writing linalg algorithms", in which case we'd all have to bow to Fortran anyway. Your argument also doesn't apply to GUI apps, anyway. C# and Java amount to a huge number of such apps, and they're self-hosted. GC languages are vastly more productive that manual-memory languages, and for the vast majority of users, that is worth the performance hit.