It just worked. It compiled without hassle. The language was easy to understand - i first read about a few days prior to writing my lib.

I absolutely think this language should get more attention, and probably it should explore wasm a bit more. I know webdevs love easy to read languages and DLang is an ideal candidate for replacing javascript in the browser via wasm.

All it needs is a nice package manager and a set of basic web libs to use in the browser - not the DOM kind of libs, but for large’ish tables and data manipulation, a bit of audio and video editing and perhaps webgl integration to showcase what it can do.

/end of babbling

Well, I wrote a version of my support library for those games for webassembly too and you can play some of them online!

http://webassembly.arsdnet.net/

None of them are "finished" per se, I'd be on a strict time limit and just left it where it landed when I ran out, some not even really working, but there's some little playable chunks there. Tends to be 60KB or so of webasm, really not too bad (no need for the emscripten bloat etc since I did it all myself)

It amuses me to compile the same program for Windows, Linux, and the browser without modification.

(that's all I personally use webassembly for though, since I'm not a fan of SPAs...)

after trying zig, i also wish C interop was as smooth, but zig has advantage of shipping a clang compiler as library, D could do the same since they got LDC (with LLVM)

i move between zig/rust and D; i'm happy to say that we can live in a world where we can totally ignore c++

Also remember that the GC is entirely written in D, it is possible.

When i say available, i mean available out of the box

Luckily, that seems to finally have reached a "yes!". Development continues, but nobody's getting the rug pulled out from under them anymore.

That really arrived with Andrei Alexandrescu's book which was 10 years ago now.

HN is an outlier in that people have even heard of D, for some perspective.

[0] http://www.dsource.org/projects/tango/forums/topic/920

Part of the evolution of breaking changes that would eventually be labeled "D2" was upstream merging in those incompatible bits. So the user-level API of Tango kinda died out - kinda, it is still around but not many people still use it - (as did the Phobos user-level API from that era btw, most of it anyway got replaced in the evolutionary process too) but the actual runtime parts actually just got merged upstream, bringing the two diverging branches together, and are now called "druntime".

But yes, all of this was weeeeell over a decade ago. Despite having experienced this friction back then, I still think of D as an extremely productive/pragmatic language with a snappy compiler. Some of the stuff that pops up here and there about new developments in D2-land are also very interesting. If anyone's on the fence about it, I would definitely recommend giving it a shot.

But with the incompatible language runtime components, you couldn't merge the user level libs either. The base Object and Exception classes worked one way in one lib but another in the other and both used the same underlying function names leading to a linker conflict. The user-level namespaces in D are always isolated to modules, but this low level language runtime is global.

That was solved when the Tango requirements got merged upstream.

I'm a bit irked personally at people saying "D1" vs "D2" too. I use scare quotes because they actually came out at about the same time. There's only really one D language that's gone through a consistent evolutionary process.

In January 2007, a "stable" branch was arbitrarily forked off the language. This was labeled "D 1.0". It wasn't exactly stable yet; it still got some new features and even some breaking changes applies to it from the dev branch, but most the more experimental stuff didn't get merged.

In summer 2007 - mere months later - the "dev branch" got arbitrarily rebranded "D 2.0" There was nothing particularly special about that release, it didn't even have any real breaking changes. It was just slapped with a new label, but this was the ongoing evolution D has had since the beginning.

A little while later, the dev branch, aka D2, did start getting some more major breaking changes, like the const and immutable system being added (at first nothing broke, but then the type of string literals was changed from char[] to immutable(char)[] and that was a fairly big change since strings are used everywhere), while the stable branch, aka D1, would start to get only bug fixes.

People call this a "community split", but that's just not really how it happened. The stable branch was mostly maintained for a few corporate clients who didn't want to adapt to an array reallocation change in the runtime (despite general agreement the new way was better, they were just heavily invested in the old way and it would take some time to confirm their code wasn't adversely affected) while most everyone else embraced the ongoing evolution.

There were a few years of kinda obnoxious churn - I remember being quite annoyed when the std.string tolower got renamed to toLower among other "consistency" updates - but like it really wasn't that big of a deal for most of us.

I think it was a mistake to call it "D1". It should have probably just been something like "D extended support edition". But the name was what it was and online commenters continue to misrepresent what actually happened now, 14 years [!] (yikes i've been in the community a long time now) later.

https://code.dlang.org/

it ... works

That's as much as I think can be said for it. Dub is garbage. It's too complicated, too rigid, and it does too little. It's also slow for larger projects because it doesn't do incremental builds.

Note that in most cases an incremental build isn't really required for D because for moderately complex projects you're often limited by linking speed, not compiling speed.

0. https://github.com/atilaneves/reggae

HTML's canvas might be an adequate stop gap, but it really doesn't seem like an acceptable solution in the long term.

[0] https://www.qt.io/qt-examples-for-webassembly

https://p0nce.github.io/d-idioms/#Parallel-foreach

I use D as a complement to R. If I'm doing a simulation, it's really simple to shift to doing them in parallel. (I know other languages also provide such support, but I'm a fan of the overall D language as a replacement for C in the statistical computing realm.)

We do need better scientific programming libraries, however.

We do need better scientific programming libraries, however.

This is pretty much a rephrasing to few of the main goals of Julia. You start prototyping using the dynamic python/lispy, and add some typing or some optimization to got C/Fortran performance. It is really finding it's space in scientific computing. Check out Flux.jl, DifferentialEquations.jl, and SciML.jl for a preview of the cool projects Dynamic Dispatch is enabling.

Bonus points for excellent Macros: MLstyle.jl

Julia has impressive libraries, I don't really rate the language.

D gives more guarantees to the optimizer, makes it easy to give information to said optimizer and has much safer slices which prevent a lot of bugs.

For example of something cool: I have a library which can run a benchmark over a template - that is, imagine a template taking a parameter N or even a type, my library can iterate through these and perform statistics on them seamlessly.

A lot of these samples of D are really enticing and I think I'm going to have to spend some time really digging in. I hope the toolchain is nice.

Also, feel free to ask questions about the language (I work for the D foundation).

How fast is D compiler on a 100k line project?

Does it support incremental compilation?

How's the package management story and where is D heading in this camp?

Thanks!

vibe.d is quite good

> How fast is D compiler on a 100k line project?

The D reference compiler takes a few seconds on my machine and is about 450k lines.

> Does it support incremental compilation?

Not very well if at all.

> How's the package management story and where is D heading in this camp?

Uninspiring but more than enough to be productive - i.e. infinitely better than C++

On Apple M1, a full rebuild of one of my product (approx. 80kloc) is 6 seconds. 1 seconds incremental.

I have a 140k line multi-purpose library that compiles in 2 1/2 seconds on my i5 computer w/ ssd. But this varies very heavily depending on what language features you use (compile time execution of functions can make a 3 line program compile in many minutes, or simple C-style code can compile 100k lines in a fraction of a second). So don't generalize too fast!

Re web APIs, I've been doing serving and consuming with D for a long time now, I like it a lot. Using some of the compile time reflection stuff is really cool. Like this little demo site: http://arsdnet.net/cgi-bin/survey/record-survey has this source code:

``` import arsd.cgi; import arsd.dom; import arsd.jsvar;

struct Survey { string thisIsFakeDontSpendRealTimeOnIt; string whyD; int yearsUsingD; string[] thingsYouWantMost; }

struct AboutYou { string yourName;

}

class Site : WebObject { @AutomaticForm auto recordSurvey(/* @Flatten */ @DisplayName("") Survey s, @DisplayName("") AboutYou y) { struct Result { string message; Survey surveyAnswers; AboutYou aboutYou; } return Result("Thank you!", s, y); }

// you can also specify things on functions @(Cgi.RequestMethod.GET) @DefaultFormat("json") int giveMeJson(int a) { return a; }

// or have plain boring ones string hello() { return "hello, world!"; }

@UrlName("different-url") string[] anyName(string other) { return ["Hello", "Friends", other]; } }

void handler(Cgi cgi) { cgi.dispatcher!( "/".serveApi!Site ); }

mixin GenericMain!handler; ```

The form is generated from function params, the html from return values, etc. OR you can do json too of course http://arsdnet.net/cgi-bin/survey/different-url?format=json&...

so it is nice. On the client side, I also generate some code so the usage looks like

``` var result = gitlab.rest.users[myuid].pull_requests.GET; ```

and similar so it generates all those things as it needs it (the url made from the dot members, the return value just a dynamic dype). Not like perfect but plenty convenient.

Each of those paradigms has its place, and I enjoy being able to mix and match them as appropriate in the same program.

You're not forced to use the features you don't need.

There are some pain points that could probably go but realistically the aim is to make writing efficient code easy and abstract code even easier within the same language.

If you learn D you get to avoid a bunch of legalese compared to C++, and lots of runtime bugs compared to Python - there are more features to learn, but they generally make quite a lot of sense when you need them e.g. Ada-style contract programming is extremely useful the moment you don't have it.

I always had the sense - without seriously looking into it though - that D was about avoiding some of the mistakes/mis-features of C++, but C++ is always getting new stuff, which doesn't sit exactly well with what D has chosen, and then it plays somewhat clunky catch-up. But I may be very wrong.

My opinion is that D lost its goal on the way. It was indeed supposed to be a cleaner C++ without all its confusing history of layers of features over layer of features. And it was so, for sometime. But then they started adding this, and this, and that, everything and all sorts of kitchen sinks depending on the fad of the year; meta-programming, taking from C++, or lately rustifying itself. The current state looks to me is as indigestible as modern C++ (and the process to get there has largely been the same, the process the original goal of D meant to rid and avoid). A pile of templates and annotations. D's evolution has been a great disappointment to me. I can see Nim going that way too.

CTFE in D works as you would expect, constexpr is a weird hack.

Concepts in C++ are ridiculously overcomplicated and are done with a much simpler solution in D.

Ranges are also much better thought out in D.

C++ will also never replicate D's ease of use when it comes to metaprogramming - static foreach and if for example have no alternative in C++ (if constexpr is incredibly stupid)

Sink your teeth into that. Code generation at compile time, functional programming etc.

The compiler can actually check that this is pure for you but in this case it isn't performed so it can read from stdin

Would you care to elaborate what's wrong with it? When I used it I always felt it was quite straightforward.

Constexpr tells you what you can do. It adds huge amounts of bulk to the standard, there is syntax soup everywhere now etc.

One thing C++ will never have is D's `static if`, which allows injecting declarations into scopes. Bjarne Stroustrup and others closed that door: https://isocpp.org/files/papers/n3613.pdf

don't be so sure

https://github.com/lock3/meta/wiki/Metaprogramming-Introduct...

a lot of it is already implemented: https://cppx.godbolt.org/z/4arx6T

See e.g. https://youtu.be/8c6BAQcYF_E

The following example is similar to C macros because it generates code as string and mixes it in as code but you can combine templates as well. This example generates a struct definition.

(Edit: formatting)

  import std; // Entire package for brevity
  
  auto memberDef(string type, string name) {
    return format!"  %s %s;"(type, name);
  }
  
  auto memberDefs(string[] members...) {
    return (members
            .chunks(2)
            .map!(pair => memberDef(pair[0], pair[1])));
  }
  
  auto structDef(string name, string[] members...) {
    return format!q{
      struct %s {
        %-(%s%)
      }
    }(name, memberDefs(members));
  }
  
  unittest {
    mixin (structDef("Foo", "int", "i", "double", "d"));
    auto f = Foo(42, 1.5);
    assert((f.i == 42) && (f.d == 1.5));
  }
  
  void main() {
  }

For example C++20 has constexpr, consteval, constinit, for a less powerful equivalent of D's CTFE.

D use no syntax for this. Things are evaluated in CTFE when they can. The rules are simple, and you can ignore them for the first few years. It's because CTFE is considered a normal thing in D.

Features I absolutely love that I wish I could use at work (stuck in C++98 land, slowly upgrading) include ranges, template metaprogramming, and inout. So much of the surrounding toolset could be removed if only I had those capabilities.