Hacker News Reader

Comment by thiago_fm | Hacker News Reader

Can somebody enlighten me, why use D when there is Rust/Go?

I think on almost all cases, and also having a bigger community, it is a win for Rust/Go.

I find D easier to use than Rust or Go because of familiarity. It is very obviously C and C++ inspired but without all the sharp edges.

I also love D's metaprogramming. It feels almost like lisp. Go's lack of generics doesn't allow this and Rust's macros don't feel as comfortable for me.

Yes, D is smaller but it's also big enough for me. I don't feel like I'm missing out on much when I'm using D. If I need a library to do something that isn't already in the fairly generous stdlib, I can find it on DUB.

http://code.dlang.org/

Good post. I haven't used D much, but the only way I really see it as "deficient" is its inability to easily create static binaries, like Go. But in a lot of ways that is never a hard requirement (it is nice, though).

Why can't D create static binaries? I've never heard that before.

I have never heard of that before. I create and link static libraries all the time. My exes are usually a drop in without any dependencies whatsoever.

Sorry -- it can, but in much the same way GCC does. You need to manage all your deps. With go it just happens, a huge time saver.

I'm pretty sure Dub will happily manage your D deps and compile them statically.

But I appreciate how that's not necessary and I can use only system-installed libs with Meson and pkg-config :P

There is no issue creating static binaries.

You're mistaken. By default D statically links all D dependencies (leaving only libc and possibly OpenSSL (if you need it)) to be dynamically linked (which has it's advantages), but if you want you can statically link all dependencies (including the C ones), just like you can with C or C++. D produces the same format of object files as C/C++ which makes this just as easy.

I think D is still working through lack of support for dynamic libs (lots of headway was made so I may be wrong)

It is funny how Go sold it as a feature, but it was always a deficiency in D (and yes, it just happened out of the box.)

That isn't to say C dynamic libraries didn't work, that is a linker thing, but it would be the same in Go.

You totally could create static libraries or compile stuff statically inside binaries to create a go style standalone executable but you need to recompile Phobos as a static lib for that

Not as exotic as Rust, due to more being in the Algol line of succession than ML's.

But boy, on the Algol-tree, it's about as far away from Go as you can, erm, go. The blog poster's predecessor was about as heavy as you can get into generics without being called Stepanov.

D tends to have quite a lot of features and lets you pick your subset, which brings it closer to languages like C++ or Scala. Go, being basically Oberon filtered through New Jersey, is a lot more minimalistic. Old Java vs. new Java, basically.

I'm not exactly averse to templates...

https://atilaoncode.blog/2015/02/11/the-craziest-code-i-ever...

Compared to Rust: smoother learning curve, and you don't have to fight the compiler so much

Compared to Go: much better designed and richer language.

Obviously in terms of community, it's much smaller. But if you're ready to "build vs buy" more, or if you have some small scope project, I'd encourage you to try it.

"Fighting the compiler" is a common annoying stereotype, quite often quoted by people who don't even know Rust. After a while of using Rust, you no longer fight the compiler, you know how things work, you design and structure your programs with borrowck in mind from the start.

Initially coming from C++ background, e.g. I had good understanding of its ownership model with move vs copy semantics (unique_ptr vs shared_ptr), I read many Rust blogs, watched a couple of tech talks and read several chapters of the book, so everything looked super promising. I even spend reading about linear and affine type theory.

But I can testify that spending my first days with Rust was a struggle the whole way. It's probably because D had spoiled me a lot by the time I got to Rust. After some time I lost interest as Rust didn't offer anything that I was actually missing in D, while D had much to offer in the areas of things I liked.

Try to write a GUI application in Gtk-rs, or a game engine with the vector clocks array workaround, and you will see that many of us do indeed know Rust when we complain about fighting the compiler.

I work in c++ and D was designed in part to address a lot of c++ complaints. so I find myself with very few issues while writing D. it's just a very enjoyable experience (subjective ik)

the meta programming is very cool also

I am worried the push towards integration with C++ will just turn D into a cheap C++ clone. We already got copy constructors, just to interact with C++ code. More C++ features to come.

Copy constructors were needed due to type checking const/immutable copying. C++ interop was just icing on the cake.

It's the other way around, C++ is turning into a complicated D clone.

Nothing cheap about being way ahead of C++ in metaprogramming and compile-time programming.

Well, for example:

  import std.stdio;

  struct Math(string Op) {
    static auto eval(T, U)(T l, U r) {
      static if (Op == "+")
        return l + r;
      else static if (Op == "-")
        return l - r;
      else static if (Op == "*")
        return l * r;
      else static if (Op == "/")
        return l / r;
    }
  }

  static immutable auto result = Math!("+").eval(1, 2) + Math!("*").eval(3.0, 3.0);

  void main() {
    writeln(result);
  }

You'll never be able to do anything like that in Rust until const generics are not only complete on their own, but also fully compatible with "const fn".

Assuming I formatted it right, I made your example shorter

  import std;

  template Math(char Op) {
     auto eval(T, U)(T l, U r) {
        static foreach(x; "+-*/") {            
         if (Op == x)
          mixin("return l ", x, " r;");        
        }        
    }
  }

  static immutable result = Math!('+').eval(1, 2) + Math!('*').eval(3.0, 3.0);

  void main() {
    writeln(result);
  }

Yeah, that works too. I was trying not to get too crazy I guess. And also just show all the various levels of "static".

It's easier and more productive than Rust and has generics, templates, better C interop than Go. Also the GC can be disabled or worked around.

Rust is pretty low level. As a Python programmer I can use D a lot easier (with the exception of templates and all the stuff that assumes you know C++ which I don't) than Rust as I don't have to worry about memory.

D is easier to use than rust and way more capable than go.

While not a targeted answer to why not go/rust, this is my case

https://dev.to/jessekphillips/my-case-for-d-444p

When you believe in systems programming languages with tracing GC support, powerful metaprogramming and generic code capabilities that compiles as fast as Go.

.. and with much better run-time performance than Go.

Reply on news.ycombinator.com