My Vision of D’s Future | Hacker News Reader

My Vision of D’s Future

dlang.org

262 pointsingve208 comments

As someone who has only somewhat recently started using D, I would love to see this language succeed. It's been such a pleasure to use.. scope guards, string mixin, inline json & std.json. It's been so useful for the code I write at work. Much love for D

The one thing I would add to this list is documentation! There is a lot of good documentation available, but not for everything you would expect. For example, I had a hard time figuring out the behavior of sub-packages within a dub package. Some more explicit documentation on this subject would have been appreciated.

I find that D is about as easy as Python to get into. Being able to use rdmd as a shebang makes D almost feel like as scripting language. A lot of Python was also pretty easy for me to directly translate into D. Here is an example:

http://inversethought.com/hg/medcouple/file/tip/medcouple.py...

http://inversethought.com/hg/medcouple/file/tip/medcouple.d#...

While I enjoy using D, I find it hard to use at times. Especially if someone isn't a C++ veteran, as soon as heavy template usage comes into play I get confused, and error messages are useless because it's several screens of errors with multiple isX() && !isY() && isZ() conditions for types.

Most of the standard library function calls return some opaque Result type which isn't obvious how to progress from. Only after some googling you'll learn that if you import std.array you can use .array() on the Result and get something usable. Oh, and I don't even know if it's possible to pass such Result to a function because you have to use auto to declare it.

Yes, there's an extra barrier with D because of type checking, but in exchange, you get compile-time checks. I actually kind of like those template errors because they tell you what kind of Python-like compile-time duck-typing D is trying to use!

Oh, and you can also use type deductions for function declarations! Just make it a template and let D figure out for you what type you want, or use typeof to record the type you want and use that typename in your function declaration.

That second feature sounds really neat. I'd always wished Go had implemented something like this, even if just for numeric types.

just use a wrong type (bool lets say), and check out go compilation error. it will tell you what type it wants.

For what it's worth, I'm a long-time C programmer, but have piss-poor C++ skills, and despise C++, and D clicked for me immediately. I'm loving it.

Whether D "clicks" for someone might be more a matter of subjective taste than what languages they're used to.

As for D templates, they puzzled me until I read Andrei's D Programming book, which made everything clear. They're less narrow than C++ templates, more like directives for a syntax/scope-aware C preprocessor.

You can use them for more than just polymorphic functions; they're a way to pass source code around the program at compile-time, for almost any purpose whatsoever.

I've written like one C++ program in my life and I had no problems figuring it out. Although I write C somewhat frequently and have done a lot of Haskell stuff. I think experience with any statically typed language is going to make it easier to learn another one.

Having to use .array() on the Result of some functions is the exact same problem I've ran into as well! D is by far my favorite language but there is definitely some room for improvement in terms of documentation on how to use the standard library.

On the other hand, I like the explicitness of it instead of automatically converting to a different type. At least you know exactly what it's doing.

The python version of it would be calling `list()` on things all the time, which you might not always want to do.

That's a fair point. I'm not necessarily against having to do it, I just would like there to be a more obvious indication of how to convert the result to an array. It took a lot of searching the first time I came across this.

Perhaps it's just my own incompetence though!

It's definitely not your incompetence. I started learning D a few months ago and it didn't click until someone on IRC explained it clearly to me. It's not in the tutorial or anything unless I missed it.

It is the first thing I added to my articles when I introduced range based operations :

https://dev.to/jessekphillips/count-of-a-list-in-d-49k4

It's not the best idea to always unconditionally use .array because you might want to preserve the laziness of a Result type. By using .array you're saying you want all of the results into memory right now! Depending on what you're doing, you might not want that.

I actually didn't know this! Very cool. I guess it's similar to calling .ToList() on IEnumerable<T> in C#.

Most range function return a "Voldemort" that preserve lazyness if you put it in an `auto` local. Or you can use .array to get a slice out of it.

> Most of the standard library function calls return some opaque Result type

This is by design, e.g. map could not be lazy if it returned an array.

> Oh, and I don't even know if it's possible to pass such Result to a function because you have to use auto to declare it.

templates, void use(T)(T x) [auto ref if you feel fancy]

Let me give you a little guidance on this (if you happen to still be using D). Most functions in std.algorithm (and many more throughout the rest of the standard library) return "ranges", which is like a begin iterator and an end iterator zipped up into one data structure. There is a "range hierarchy" that mirrors the C++ iterator hierarchy:

Input/Output Range > Forward Range > Bidirectional Range > Random Access Range

Input ranges provide the following API:

    bool empty()
    T front()
    void popFront()

Forward ranges provide the same API, and also add a "save" function that creates a copy of the range's current state.

Bidirectional ranges add "back" and "popBack" functions, which don't really need any explanation.

Random access ranges additionally add a "length" function and constant-time array-like indexing.

In addition to most functions in std.algorithm _returning_ ranges, most of them also _accept_ ranges. Therefore, you can freely pass the result of any function in std.algorithm into another function that takes a range, and it should all just work. It's pretty much the same deal as in Rust/Java/Swift/etc. with their various iterator protocols, although the API for ranges in D is more influenced by C++.

For example, the first Project Euler problem, using a range-based approach:

    import std.algorithm;
    import std.range;
    import std.stdio;

    void main()
    {
        //List all the natural numbers below 1000 that are multiples of 3 or 5
        auto natsBelow1000 = iota(1000); //iota returns a range that lazily computes the numbers from 0-999
        auto multiplesOf3Or5 = natsBelow1000.filter!(n => n % 3 == 0 || n % 5 == 0); //filter accepts a range as an argument, which it lazily filters according to the given predicate
        auto sum = multiplesOf3Or5.sum(); //Sum accepts a range of "summable" items and computes the... sum
        writeln(sum); //Prints 233168
    }

A D programmer wouldn't generally write things this way, preferring to make a more idiomatic "range chain" like you'd see with Java's streams or Rust's iterators, but you get the idea.

As you might have guessed, arrays are also ranges - random access ranges - which is why they're so easy to use.

I would highly recommend against putting `.array` everywhere in your code, as it will force the range you pass to it to be eagerly evaluated and allocate more memory from the GC. It's much better to take some initial data store, like an array, do all your filtering and mapping, etc. on it, and when you're done, _then_ turn it back into an array with a call to `.array`. That way you'll get all the lazy iteration and low memory footprint of ranges, and then at the end you have a nicely allocated array of data with the result that is easy to work with.

Honestly, though, in most of my code I usually just pass around ranges as they're very good for creating interlocking adapters over different backing stores. One really great article on advanced usage of ranges is H. S. Teoh's article on Component Programming with Ranges: https://wiki.dlang.org/Component_programming_with_ranges

A couple great resources on ranges in D:

http://www.informit.com/articles/printerfriendly/1407357

https://tour.dlang.org/tour/en/basics/ranges

http://ddili.org/ders/d.en/ranges.html

http://dconf.org/2015/talks/davis.html

auto natsBelow1000 = iota(1000);

How do I pass this output to some other function without doing .array()? It's rare that you do all your processing in one method. Should I do this:

void processFurther(T)(T t) if isInputRange!T { } ?

I mean, it would probably work, but I don't like how the conditions are detached from type definitions :S

Yes, or if you don't want to use a template function, for whatever reason, you can wrap the result of iota(1000) into an InputRangeObject (see https://dlang.org/phobos/std_range_interfaces.html#InputRang... for an example).

> I don't like how the conditions are detached from type definitions

I can understand that; it's something that takes a bit of getting used to. See https://dlang.org/concepts.html for an explanation of template constraints and why they were designed this way.

Uniform Function Call Syntax is one of my favourite things about D

I also have this problem. I find part of D is easy like Python, but all the template jargon is over my head.

Yes on documentation. They have a beginner's book and everything else is pretty advanced or reference material. Some additional intermediate content would be good like how the Julia project does it.

There are a couple of good D books on Packt.

https://www.packtpub.com/application-development/d-cookbook

https://www.packtpub.com/web-development/d-web-development

https://www.packtpub.com/application-development/learning-d

Plus buying them is a way to support some community members.

the #d channel on freenode is extremely helpful and knowledgeable though, which helped fill the gaps for me personally.

>I think we need a ridiculously fast interpreter so that we can skip machine code generation and linking. To me, this should be the default way of running unittest blocks for faster feedback, with programmers only compiling their code for runtime performance and/or to ship binaries to final users. This would also enable a REPL.

I am most excited about this, where a language supports two modes 1) interpreter for development, and 2) compilation for performance. Never thought about this, but reading this, it makes perfect sense on large projects

I'm a fan of Go's "go run". For example, you can do:

  go run main.go

or:

  go run ./cmd/server

When invoked this way, Go compiles your code behind the scenes, but you don't have to create a binary.

This means Go lends itself pretty well to ad-hoc scripting or writing small script-like tools.

Unfortunately, Go doesn't support shebang lines, but with gorun [1] you can:

    #!/usr/bin/env gorun

    package main

    func main() {
      println("Hello world!")
    }

[1] https://github.com/erning/gorun

D's default package manager already allows you to write code like this which 1. runs the code like a script 2. downloads dependencies if they are required.

    #!/usr/bin/env dub
    /+ dub.sdl:
        name "allthepythons"
        dependency "d-glob" version="~>0.3.0"
    +/

    import std.stdio : stdout;
    import glob : glob;
    
    void main () {
        foreach (entry ; glob("/usr/local/bin/python*")) {
            stdout.writefln("%s", entry);
        }
    }

Dub's documentation should use some love...

D already works like this.

Scala (Ammonite) works like this.

The author isn't complaining about keystrokes; he wants the compile + run process to be faster. Using an interpreter instead of a compiler would make it faster.

Java has the same now (since Java 9 I think).

So you're saying it's as simple as:

java build ./app/ ./app

That's impressive if true as last I worked with Java it was a mess

Not quite. You can run `java Foo.java` and it will compile and execute the class file (and remove it when done).

D compilers do work as a shebang already.

I actually use this for all of my complicated build scripts and just use make to glue them together. For instance I have a stack name from computer,branch,sha,username that I calculate so I have a different stack per thing I'm working on. I tried getting that to work with awk fu but doesn't work the same on every platform, so instead "go run cmd/get_stack_name/main.go" instead. Fast and like it.

OCaml works like that

Haskell too.

Add Flutter to the bunch - having a fast interpreter is especially pleasing when the result is an instant visual change the app running on an emulated android phone.

Java can do this via AOT or partially also JIT compilation.

For AOT there is this JEP: https://openjdk.java.net/jeps/295 and a different project: the GraalVM

Java could do this always, as it's a compiled language (the important thing here is interactivity vs. compilation, not JVM vs. native).

So I'd say that Java can do "this" since recently (JDK 9 in 2017) via JShell (I wouldn't count BeanShell or Groovy), i.e. it always had the compiler part but added the interpreter.

Although its usage is still quite rare, whereas the blog post would suggest a different pattern.

As addendum, Java has had support for AOT since around 2000, the only caveat is that it has been a feature only available on third party commercial JDKs.

GCJ improved very slowly and around 2009 lost most of its developers with the release of OpenJDK.

JIT runtimes try to give you both.

It starts interpreted, but if you run for very long, it runs compiled.

But that costs memory and startup time.

Most JIT runtimes also can't produce a standalone binary

Pretty much all JITs have tools for standalone binaries.

People usually don't do it because JITs are heavy so they'd prefer to share them.

I have to say, I like what I read there. I'm glad they're working more on c++ interoperability. I've ported some c++ code to D before, it wasn't not too bad, it wasn't a lot of code, but it would be great to be able to work directly with c++ libraries in D similarly to C libraries.

It always makes me sad D hasn't picked up more. Usually comments I see about D seem pretty ambivalent to dismissive. It's a great language and to me has always felt like the way C++ should have been.

It does seem to be growing in popularity. Even in the years I've been using it, the number of libraries and community resources has expanded exponentially and every day new code is being added to

https://code.dlang.org/

Not to mention dub is probably the most simple straightforward build system I've worked with.

The main reason that D hasn't been picked up by anyone is mostly because it is an evolution of C++, not a revolution. Discarding an entire ecosystem for an evolution is not going to happen. Rust took a very different approach and just threw everything away. D looks and feels too much like C++, I would rather have hoped that effort would have been spent on making C++ better.

It might look like c++ but I can't say it 'feels' the same. The lack of header files in D immediately jumps to mind. D's module system is totatlly different from C++'s preprocessor. Ranges and slices are a big part in D programming that's a fair bit different than the way things are usually done in C++. Interfaces, Classes, structs are handled differently.

The similarities are more surface deep once you start learning more about the different features and tools D offers.

Not really, it doesn't feel like C++. D fixes many C++ annoyances, has a GC, doesn't have the annoying preprocessor, header files.

Walter Bright did try to make C++ better, remember that D came along after he wrote the Digital Mars C++ compiler.

C++ has also improved in the meantime.

I have programmed in both for years (commercially) and don't understand the comments about D being like C++. This is a night and day difference to me.

It is less about how it feels and more about how it looks.

And appearance really only changes when you hit templates. And with D you can't tell (as an outsider) so it just looks like the non templated C++.

... and over the past decade-and-a-bit, C++ has been evolving itself quite nicely (IMHO), so the motivation for moving away from it has decreased. Also, now D probably has to "chase" some C++ developments.

The problem is that while modern C++17/20 are quite productive, we cannot get rid of C copy-paste compatibility and the errors of the past (see Python 3).

So either you work alone, in a small team that appreciates modern safe C++ (including Core guidelines), and enjoy C++, or you are faced to deal with all idiocrasies and unsafety issues from the past.

Well, it's not quite that dichotomous. It's quite possible to gradually modernize, or "beautify", an older-C-style codebase. And actually, having a transition path from older to newer code without a cliff is an advantage to switching languages.

That's funny. I like to beautify old C++ codebases by gradually moving them to C. Code is so much easier to read already without implicit member accesses (this->). When going through large codebases, that must be one of the most frequent questions I'm asking myself, "is this a global, local, or member variable?".

1. Because C has no shadowing of global variables by member variables? 2. If your classes have so many members that it isn't clear whether a variable is a member or not, that's a class design problem. 3. C is a simplistic, almost-assembly-like, language. It's a reasonable choice for some tasks, not a reasonable choice for others. We're talking about languages with stronger abstraction capabilities.

> 2. If your classes have so many members that it isn't clear whether a variable is a member or not, that's a class design problem.

Now tell me why every OOP codebase I look at has this problem. ;-)

The reason is the second "O" in OOP. Trying to switch on the type of a thing, where every thing has only one type (ignoring inheritance which is another problem, not a solution), means that people will put all sorts of unrelated things in one place.

Ah the beauty of use-after-free and memory corruption issues. /s

Try to find one here: https://github.com/jstimpfle/language

Not every project can be written 100% in this style, but the problem is very often programmers trying to mimick C++, e.g. doing object oriented fine-grained initialization/destruction stuff in C.

Will actually have a go at it.

As Google, Microsoft, Apple, Amazon have been reporting in multiple occasions, the problem goes beyond programmers trying to mimick C++.

To the point that future Android versions will require hardware memory tagging enabled on ARM devices.

Sure, I'm just saying that a lot of it is due to unsuitable approaches.

If you're actually going to look at it, I just want to make clear that I've never fuzzed it or anything, beyond running valgrind maybe twice (should be mentioned in the git log). And on the functional side, I don't even know what state this project is in. I think I lost interest in it when I needed to implement yet another way to encode x86-64 instructions, since having both floats and doubles is a requirement to run interesting things with OpenGL.

Let me know what problems you find!

I agree, however that modernization is only possible if the team actually buys into it, hence my remark about working alone or in a small team that embraces modern C++.

I didn't submit the link but I did write the blog post. AMA!

Thanks Atila! I'm curious about your work around reflection, care to give more details? This is one of the great strength of D, and having some API consolidation sounds awesome. Also: any opinion about runtime reflection capabilities? I love compile-time reflection as much as any other D user, but sometimes runtime reflection can do wonders if used parsimoniously.

I'm working on a library right now that, I hope, will have an easy to use API. It'll also have a "mixin/ctfe version", whereby all reflected characteristics are returned as strings that can be mixed in. This opens the door for runtime reflection as well. It's in the works.

I personally believe that it's all about _people_. How do you plan to push the community forward? After all everyone just shares their free time.

So far based on what I've observed, people in the D community is the biggest critique of it's own, even more so than any other community I've seen on the internet.

The D forum is full of shit posts thrashing D for what it is.

Part of my new job is trying to motivate people to do their best work. I'm still figuring it out.

In a recent blog post Walter talked about adding borrowing to D. Is this planned to be implemented and if so do you see any hurdles and/or benefits in relation to your Vision?

Looking forward what new perspective you bring to the community!

> Is this planned to be implemented

Yes.

> any hurdles and/or benefits in relation to your Vision?

Hurdles: implementation issues, figuring out later on that there are ways to corrupt memory despite the rules we come up with.

Benefits: Compile-time memory safety.

I have to admit I totally latched onto the point you made about fast development time.

The interpreter+compiler approach is something I've been pining for for a little while now. I've only just begun to punch holes in my obsessive tendency to only use interpreted languages (because I hate compile waits that much), and to me having the fast-iteration times of interpreters, and _also_ -O3 when it's needed, would be the best of all the worlds; IMHO JITs are a necessary hack for dynamic/untyped(/interpreted) languages, and there are serious real-world gains to be had from having the plumbing get done that lets people jump from interpretation, over JITs, straight to optimized AOT-compiled code.

Would be quite the project though, to port a fundamentally-compiled ecosystem like D to use an interpreter. I wonder how long a realistic timeframe to "minimally practically usable" would be.

Thinking about it, Cling (https://root.cern.ch/cling, https://github.com/root-project/cling, LGPL 2.1) wires Clang's C AST into LLVM's built-in JIT (IIUC) to get a C/C++ interpreter. D has LDC, so there is already integration of the UI/NCSAOSL and understanding of how to leverage LLVM. Perhaps a workable direction (with probably a lot of domain-specific knowledge already worked out and potentially available from ROOT) could be a Cling-like s/Clang/LDC/->LLVM ?

Another thought: using an approach like the above, it might be possible to add pragmas that specify whether functions should be AOTed or JITed, and how much JIT optimization should be done. I also wonder if the LLVM JIT can be told/forced to "precompile this specific function" (effectively AOTing just that function), within the JIT hot-code-replacement framework; if this were possible you could even hot-reload running code (with per-function/per-file/etc customizable optimization levels). IMHO it may be interesting to make this functionality available, and let the community/ecosystem work through the messiness of solving things like the struct-versioning problem. Clear communication would be important to rationalize and clarify the deliberateness of such a decision, of course, and that the language [design] hadn't gone completely nuts :) due to the number of segfaults/developer burnout/etc it would probably introduce.

> Would be quite the project though, to port a fundamentally-compiled ecosystem like D to use an interpreter.

Sort of. We already have an interpreter (CTFE!), it's just not up to the task for what I want to do with it.

What happened to Andrei?

> Thanks, Mike. And thanks to all for the concern - I also got a few private emails asking me for the juicy details. Of which there are none - my family needs me and some volunteering activities had to give way.

> As Jonathan mentioned I'm still working with my students and working on the Foundation administration, legal, taxes, and finances.

> I've been involved with D since 2005. That's an eternity in this business. I think bringing Atila to the fore is a great positive because it brings a fresh perspective and approach.

from https://forum.dlang.org/post/qj18h2$8o1$1@digitalmars.com

In DConf 2019 he announced about the health issues of his family member and why he was not able to step up and give 100%.

https://youtu.be/cpTAtiboIDs?t=3040

He is still around, but private life has gained more priority and he decided to refocus.

There was a post about it on the forums.

Is there any impetus in the community towards embedded development? By embedded I mean natively on microcontrollers, even if you were limited to 32 bit ARM platforms?

As a portion of our work targets micros, all of our code needs to be written in a language that supports micros so that we can share code. There is impetus to move on from C, but Rust is the first and only viable replacement candidate because of this.

The interpreter thing could work better in the current software landscape if it could be integrated in Jupyter notebooks.

Nowadays many people are migrating to Python to use machine learning in Jupyter or just to run machine learning code in Python.

It's already possible to use D with Jupyter, but an interpreter will make it a lot faster.

With all the libraries?

The base language is nice (and kind of expected), but for D-lang to grow in this space it needs port/replacements for at least NumPy, SciPy, Pandas, and Matplotlib.

What about -betterC? I always thought this was a nice "pivot" for D. It would be great to have more support for this direction. You can't avoid malloc there, but maybe some instrumenting for leak detection or some libc replacements that exploit or are exploited by the language.

Other than that, I'm okay with anything that was already in Eiffel or Modula-3…

BetterC was created at first to make it easier to port D compiler from C to D. Then people realized that it might be interesting to have D without GC and without runtime, because it makes it trivial to port to other platforms such as embedded, mobile or WASM.

The problem is, betterC is kind of in that awkward spot. It's not comparable to the "real" D, and if you can live with betterC, you might as well just use C and enjoy the wide C ecosystem.

But as a language doesn't betterC provides lots more useful features than C (the module system, meta-programming (imagine C with generics), scope() and many other useful things) that make it really a better language than C while still keeping C interop. I agree that it is in an awkward spot though -- and would have benefited from being it's own separate programming language. It would have been a killer feature if it could also compile standard C at the same time!

It would have been a killer feature if in betterC mode it could compile standard C programs and be a drop-in replacement for GCC/Clang :-).

You might find Atila's project dpp interesting: https://github.com/atilaneves/dpp

Zig is doing this, an interesting feature.

I don't disagree with anything you say :-) but it bears pointing out that D already lets you call into C libraries without glue.

This means you can write C and use the entire wide C ecosystem, but use D for the parts of the program which make sense in D, painlessly.

> if you can live with betterC, you might as well just use C and enjoy the wide C ecosystem.

If you can be bothered to use betterC then that's probably not true. To be argumentative, C is fucking horrible. BetterC still gives you a decent chunk of D's features - templates alone make it worth the switch. No more macro spam for example.

Can you imagine how much boilerplate you'd have to write to mimic this: https://d.godbolt.org/z/3XNBFW

I wish betterC had associative arrays :(

> Traditionally this is done by specifying data structures and RPC calls in an Interface Definition Language (IDL) then translating that to the supported languages, with a wire protocol to go along with it.

> With D, none of that is necessary. One can write the production code in D and have libraries automagically make that code callable from other languages.

If you're using an RPC IDL you explicitly do not want to share that code, you want to share that API.

You could share D .di files, which are akin to C/C++ headers, but automatically generated by the compiler.

Does this work over arbitrary concurrency barriers (ie a network), or is it for libraries only?

In principle, the compile time code generation involved can generate arbitrary wrappers including networked RPC. It wouldn't be terribly hard. It just hasn't been done yet as far as I know.

This. You definitely aren't attempting to build a service in one heap/address space if you're using an RPC IDL.

You'd be surprised...

C++ interop sounds like a great unique selling point. Rust/Go/Swift can't match it.

It's not unique. Nim offers C++ interoperability too.

https://nim-lang.org/features.html

Nim does it by compiling to c++, which means it's dependent on c++. D isn't.

And what exactly is the bad thing about that?

To escape the shit show that C and C++ are in their unique ways. In my experience, one of the worst things was working on a proprietary 1M+ LoC codebase. Everything was so painful (despite the feats of engineering being put in the internal infra to support the development processes and the great team members I worked with) that I'll never go back to anything like that if I have the choice.

I'm also dissatisfied with some of the design decisions accepted into C++11/14/17/20. (Some were fixable and just plainly shortsighted IMO, but others probably not, due to the language legacy).

Don't get me wrong, I love learning from the C++ community (conferences, tech talks, blogs and checking out how open-source projects that I'm interested in are implemented), but once that I had tasted the power and freedom of D going back to C++ feels like a huge step in the wrong direction.

And also being not only a user, but a contributor is immensely empowering. A PR to the standard library, runtime, compiler or package manager can take anywhere from days to mere hours (depending on the complexity of change), while attempting a change with a similar impact to C++ would likely take anywhere between months to years. And yes, I can see the value of the ISO C++ standardization process, but it's definitely not for me.

But, actually Nim compiles to C or very simplistic C++ without requiring you to write C, nor C++. For this reason there are no complications with the new C++ standards and even there is no requirement to understand C or C++. But you can easily use every C or C++ library (even the template ones) and the amount of good quality C and C++ libraries is really very huge. Almost every modern language has capabilities for linking to C, but with C++ the things are not so simple, because of the non standard ABI, across different compilers. With templates the things are becoming even more complicated. For now the easiest and the most reliable way to use C++ libraries from another language is to compile it to C++. Also by compiling to C or C++ you almost automatically cover every platform whether C or C++ compiler is available with very little special support required in the Nim compiler.

D can also use C and C++ libraries (including templates), and with gcc and llvm it covers pretty much all the same architectures/platforms as nim.

> with C++ the things are not so simple, because of the non standard ABI, across different compilers. With templates the things are becoming even more complicated. For now the easiest and the most reliable way to use C++ libraries from another language is to compile it to C++

This turns out not to be true. The only way to parse C++ is to use a C++ compiler; there is no negotiability there. However you can, as calypso[1] and dpp[2] (latter is not ready for primetime yet) do, use the c++ compiler to parse the c++ and then emit bindings in another language. As for ABI, there are really only two ABIs: msvc (which microsoft uses), and itanium (which everyone else uses). And D already implements both.

1: https://github.com/Syniurge/Calypso

2: https://github.com/atilaneves/dpp

> D can also use C and C++ libraries (including templates), and with gcc and llvm it covers pretty much all the same architectures/platforms as nim.

Thank you for the suggestion. It turns out to be correct. Obviously there is a huge amount of progress since the last times I had been looking at D, before more than 7 years. (https://dlang.org/spec/cpp_interface.html) Still the D way looks to me more inconvenient by requiring you to include the class internals into the D binding. Example from the D manual:

  extern(C++):
  struct Foo(T)
  {
    private:
    T field;

    public:
    @disable this();
    T get();
    void set(T t);
  }

Nim requires you only to mention the name of the class (template) and the public part of the interface which you actually going to use. Example from the Nim manual (https://nim-lang.org/docs/manual.html#importjs-pragma-import...).

  type StdMap {.importcpp: "std::map", header: "<map>".} [K, V] = object
  proc `[]=`[K, V](this: var StdMap[K, V]; key: K; val: V) {.importcpp: "#[#] = #", header: "<map>".}

  var x: StdMap[cint, cdouble]
  x[6] = 91.4

> with gcc and llvm it covers pretty much all the same architectures/platforms as nim

I am not sure whether they cover some really old platforms. By compiling to C you can target pretty much every platform which have a C89 standard conforming compiler.

A day ago I asked in the Dlang forum (https://forum.dlang.org/post/nmwinrjavfumvxffptxy@forum.dlan...) whether it is possible to develop in D for video game consoles, not only current generation which Remedy Games do for example, but also a few generations back. It turns out to not be completely clear, because maybe no one has tried it, but it was suggested that even if possible, probably it would require a considerable amount of tinkering. I don't know whether someone tried this in Nim but it seems to me, that by compiling to C89 or C++98, it would not be much an issue for every platform with a conforming compiler for these languages.

cfront, the original C++ compiler, used to compile to C. Why aren't we using such a compiler nowadays?

Because Walter wrote a native compiler. I could see the same fate for nim, Walter writing a native compiler for fun that is.

Why can't Rust match that?

Most languages settle down with C interop and don't bother with the added complexity from C++. Rust is one of those, some of the concepts aren't even on the language right now, what would lead to very non-idiomatic imports.

The Rust bindgen tool automatically generates Rust FFI bindings to C and C++ libraries. Mozilla uses bindgen a lot to interoperate between Firefox's C++ and Rust code. IIUC, Rust and C++ code can't seamlessly call each other unchanged, but bindgen adds FFI glue that makes it much easier.

https://github.com/rust-lang/rust-bindgen

The C++ on the documentation is there for the few places where there's nothing on the interface not supported by Rust. Notice it says it generates biding for "C (and some C++) libraries".

A C interface on C++ code is how most people do interoperability with C++ libraries. It is pretty much C, so you can just use the FFI. But it's not really a C++ compatible FFI.

Rust doesn't have classes, for one?

More specifically, Rust doesn't have inheritance of data. It uses composition and can simulate inheritance of interfaces. That suffices for Rust programs, but gets awkward quickly with some classic OOP-heavy design patterns.

Despite superficially similar angle bracket syntax, C++ templates and Rust generics are very different and incompatible in all but most trivial cases. D templates can get closer.

Rust also lacks many C++-isms: there are no copy/move constructors, no custom code can run on assignment, operator overloading is more conservative, there's no life before main(). Error handling, iterators, and strings are done differently.

Even if C++ could magically work in Rust, it'd be weird. OTOH D feels much like a rewrite of C++.

Seems like Mozilla uses Rust with C++ in Firefox on a daily basis: https://news.ycombinator.com/item?id=21262860

> We’re mostly there—using the actor model eliminates a lot of problems that would otherwise naturally occur.

So D comes with an actor system baked in at the language level? I like that sort of thing after using Erlang and using some half baked libraries in other languages.

I’m curious how good it is...

D comes with a lot of "casual parallelism" baked in at the language level, and in its standard libraries. Actors are just one feature among many.

You -can- explicitly manage threads and processes like in other languages, but much of the time there is a more lightweight, expressive construct available.

For instance, you can turn this loop: foreach(ref i; arr) i = i * i;

Into a parallelized loop by simply: foreach(ref i; parallel(arr)) i = i * i;

Example was shamelessly lifted from: https://tour.dlang.org/tour/en/multithreading/std-parallelis...

Much like immutability, I don’t generally find it compelling when a language offers such a critical feature as just one among many. I prefer my languages to be opinionated.

I’m curious how the actor model works on a large system with lots of 3rd party libraries (or even different development teams) when you can’t guarantee that everyone is using it.

Yes! I've only used it minimally in a non high load scenario, but it's been a pretty smooth experience.

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.

D needs to up its game with the Techempower benchmarks IMHO. Vibe.d has been completely left behind by the usual Rust/Go/Java suspects. I'm very confident that it is capable, but that isn't particularly obvious atm.

I was curious. The best entries for D on physical hardware:

    JSON serialization:    144 of 366
    Single query:          152 of 404
    Multiple queries:      195 of 394
    Fortunes:              154 of 371
    Data updates:          99 of 365
    Plaintext:             81 of 352

I don't think anybody really cares about the Techempower benchmarks. Else we'd all be using Vert.x or so.

The most popular frameworks having the 90% of deployments, are at the middle to bottom of the Techempower benchmarks.

I think people thinking about using D care a lot about benchmarks. The reason "most popular frameworks" are in the middle to bottom of the list is becaue they are made with dynamic languages which are/were very popular for ease and speed of development, with a huge number of web-programming functions baked in.

On the other hand, you will note that go / rust and C frameworks (which are playing in the same field as D) are on the top of that list.

We actually do care about those benchmarks. At a certain scale it matters how many servers you need to run a website with millions of visitors. 90% of deployments do not have this problem, yet saying nobody cares is a bit silly.

At that scale do you use a stock framework though?

An advantage of D in that situation is how easy it is to change the internals of an API without those changes propagating to the surface, both by design (e.g. UFCS, no brackets) and how that design is used (e.g. Templates)

Yes you do. You do not want to write everything yourself.

Wow, Rust is a beast.

I think this is more of a measurement of how much effort people have spent implementing the benchmark, e.g. Based on a cursory look six months, a few of the rust ones seem to have been implemented with some parts from scratch rather than just hammering it together like the D implementation.

There was also one where dmd was faster than ldc, so something must be up somewhere

This is excellent news for D, Atila is a great choice for this role.

I can never believe how fast their forums load

It is written in D.

Minimal javascript

I would love to see D succeed as the king of interop. That would be a great niche to fill.

The one comment on the article on the page I think is spot on - I think every programmer language designer underestimates the importance of good IDE support.

> I think every programmer language designer underestimates the importance of good IDE support.

Oh, we're well aware of it. It's just that the language design part consumes all our time.

Thankfully we've now got LangServer thanks to Microsoft which helps tremendously! It means any IDE / editor can be useful once at least a single LangServer project is made per language. Code once, use anywhere!

A good IDE used to be my hangup for D but VS Code has a very solid plugin.

I love D and one space I want to see more of is DMD on SBC's and moreso than that D running on WebAssembly, Go and Rust do it. I consider Rust and Go the main competitors to D, not sure if others would agree, but that's just my view. Other than that it's a great language.

Let's be real, in the real world D, go or rust are not competitors to anything. Just take a look at http://www.modulecounts.com to see the gap between language ecosystems.

Using module counts is an odd metric. Languages mean much different things by modules and have radically different cultures surrounding the size and scope of a module. While an interesting metric to track, it is pretty meaningless as any sort of popularity measurement.

I'm not sure I agree with "real world" being the number of publicly available packages. Better metric is companies using those languages:

https://dlang.org/orgs-using-d.html

https://www.rust-lang.org/production/users

and we know plenty are using Go in prod, including Slack, Google (heavily for YouTube's database layer), and many others.

Why did you link to start of production page?

https://www.rust-lang.org/production/users

has all production users (it admittedly has a lot of Bitcoin Startups). But lacks some important users like Microsoft (for ripgrep in Visual Studio Code) and Facebook for its usage of Rust for Mercurial (admittedly this isn't production ready).

I hadn't been to their users page in a while. I'll update my post.

ldc does support webassembly.

It would also be good to know a high level timeline of all these visions. Otherwise these visions will just be visions forever. For instance, https://wiki.dlang.org/Vision/2018H1 directs to https://github.com/dlang/projects/milestones but both there seems no updates since April/May 2019.

Edit: added previous "vision" links

I wish standardizing documentation tooling (everyone uses a different tool today and ddoc by default has _no_ styling, no navigation, no nothing, so usually nobody writes docs for their code unless it's a big project like vibe.d) and IDE support was on this list (vscode centric tools exist and mostly work, but it's still fairly hit and miss) .. D's tooling has languished for a long time even if it is a great language otherwise.

I've been working on that with my dpldocs.info site. Dub packages get linked to it automatically unless they manually override (which I didn't want to allow in the name of standardization but got overruled :( )... but like tons of things are still just plain missing docs and nothing I can do about that automatically.

We are considering hurting their search result score based on doc coverage tho.

Visual D with Visual Studio is the gold standard, with full debugging, autocomplete, and static analysis support.

Code-D with VS Code is also great, and it has fairly recently gotten funding from the D Language Foundation for further development.

There's also DCD, D-Scanner and dfmt which can be used with a lot of different editors.

Also, what's the difference between code-d [1] and dlang-vscode [2]

[1] https://marketplace.visualstudio.com/items?itemName=webfreak...

[2] https://marketplace.visualstudio.com/items?itemName=dlang-vs...

Edit: It seems that dlang-vscode recommends to instead use vscode-dls [3] or code-dlang.

[3] https://marketplace.visualstudio.com/items?itemName=LaurentT...

Do either Visual D or Code-D work with Linux or WSL? It would be really nice to have the GUI for debugging linux code. Some libraries are just much easier to get set up in linux.

Visual D is a plugin for Visual Studio, so no. Code-D is a plugin for VS Code, so it works anywhere VS Code does.

I don't like D mainly because of the whole dichotomy between structs and classes (and also because of many other smaller things).

But I don't think D hasn't succeeded in replacing C++ for this reason; the reason D hasn't succeeded yet is because it's relatively unknown in the enterprise developers circle. Most people haven't heard of D.

A major missing feature is checked exceptions. See long discussion thread here: https://forum.dlang.org/thread/hxhjcchsulqejwxywfbn@forum.dl...

This is glossing over the fact that checked exceptions are a very controversial feature and that most language designers (is there any language besides Java that supports them?) do not implement them on purpose.

Why is it controversial? The controversy came from C# vs Java and if you have programmed in both you’d know that exceptions are broken in C#. Broken because you have to catch the base Exception class if you want to avoid crashing and that’s disrecommended by all C# linting tools.

Nim supports them with the raises pragma

I would like to have a java to D, because a lot of scientific libraries are done in Java. If the interop is easy and can automagically create Java compatible libraries from D, it is a big win. Hopefully it is in the roadmap. C++ interop not that much for me.

There is a lot of good documentation available

As long as we search for stuff on the internet with text terms (i.e. Google) you've got to enhance the name of the language. If only something boring as DLang, please please do this.

I feel bouts of sympathy every time I think of D, and I'm not even a hard core fan or anything.

No need to change the logo or anything. Just sneak in something actually searchable (dlang, or whatever) in footers and headers of documentation etc. Then just stick to it and Google will do the rest for you.

The domain is dlang.org, the github repository is called dlang, the titles of their pages are things like "Dlang tour" and "Dlang forums". It's already searchable as dlang with no issues.

The sad part is, every time I type dlang in google for something, it tries to correct it to golang and that's terrible. duckduckgo doesn't do that.

>every time I type dlang in google for something, it tries to correct it to golang and that's terrible

Doesn't do it at all to me...

1. https://i.imgur.com/CzGesdb.png

2. https://i.imgur.com/hlGGwWO.png

3. ...

I see. I can get some of those too.

Thought you meant the "Showing results for xxx / Search instead for yyy" correction, which switches your (unpopular) yyy query under you.

The suggestions are annoying, but can easily ignore and insist on my search term.

I just tried and there is literally no mention of golang in any of the search results

I mean, Go is funded by google. So, that's kind of what you get when you use a search engine that is run by a major advertising corporation, I think.

I hold a rather controversial (at least for HN, apparently) opinion that, I don't think we can expect a corporation to be impartial if there's no legal impetus on it and there's no monetary reason for them to act impartially. Google is a business, that makes money from selling your searches and displaying advertising. So, it's going to do exactly that.

Did you try typing it in ? It does nothing of the sort and goes to dlang's page.

https://spreadprivacy.com/google-filter-bubble-study/

I guess I also mean actually referring to it more as DLang (or something) so people start calling it that. "D" is so hopeless to even use in conversation. Even "Rust" is miles better, and that's not exactly a brilliant name either.

>"D" is so hopeless to even use in conversation.

Not any more hopeless than one of the top-10 most popular languages, C.

Except if you mean the juvenile joke it alludes to, in which case, nobody really cares between adults. No company is not gonna be use D because in some memes it means dick. Libraries, tooling, maturity, devs, speed, are the real concerns...

There's nothing wrong with juvenile jokes; we can be adults without being prudes. The only issue with D is the well runs dry pretty quick.

Yeah, you don't want to know how many times I have said "I work with the D Programming Language" and people are like "are you a psychologist like deprogramming brainwashed people?"

Though I usually just shoot back "no computers. code people just suck at names"

It's beyond me why most languages fall into this trap: C, C++, C#, D, Go, etc. All hard to search for. Granted some of these predate the internet, but most do not. Almost looks like some kind of secret agreement between language designers.

I’ve used all of those languages and never had a problem searching for things for any of them, with the exception of C# very briefly at the time it was released.

Whenever this complaint is lodged I feel like it’s just an easy thing to complain about that isn’t an actual problem at all. Am I wrong?

What you call trap I call tradition. There is a limited number of one letter names, getting your language to be identified with one is a big achievement. For D in particular, there has been a long competition to become "the next C" and the name has helped D to always be considered a contender.

And it does not poses such a problem for searching engines in practice. At the end of the day, you never search for "C", you search for something like "pointer to function in C" and probably much more specific, so any search engine will give you right results.

I'm going to name my language after ' ', ascii 32

What about lower case c

Google for "dlang" (including the quotes) and you'll get all the D hits you want.

Not only has that been happening for years, Google will match D when you search for dlang, wouldn't be surprised if the reverse is true. Google has figured this out for you.

Yes, this is why the Go language was a complete failure too. And C before that.

You speak as if you've never coded in Go before. If you've ever tried looking up information related to Go online, most of the time you'll find that results come up unrelated due to the short moniker. I've made a practice for myself to always search up "go" first and then "golang" because of how varying the search results tend to be, which leads me to also believe that much of the online knowledge related to Go tends to fall through the cracks due to bad SEO.

This reads as if you're willfully misunderstanding the other person's point just so you have an excuse to leave a snarky comment. There are lots of other forums for that.

Tbf, C was big way before Google even existed (and nobody expects "Clang" to mean C, unlike D or Go). And even if it obviously didn't cause Go to fail, it's still something annoying when googling up about Go, because "Golang" doesn't always work.

Reply on news.ycombinator.com