I like to write really basic little games to kill time. Stuck on a flight? Clone tetris or minesweeper or whatever. And of course I use D.

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...)

That's really cool, thank you for sharing! It is neat to see a bit longer form D code in more than just sample tutorials.

i love D, i only wish story where non-gc is needed would improve (more allocator work, more gc free runtime etc)

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++

@nogc is growing, and memory safety will also be improving, just that we've basically reached end of what we can do before reaching the hard problems - we're definitely not stopping we just need to get any changes to the language right.

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

There's also Calypso, an LDC fork that can process C++ headers directly. It should in theory also work with C.

why a fork, and not a PR to LDC? fragmentation is a bad thing in my opinion

Because merging an increasingly large subset of a c++ compiler into a compiler for a different language is a recipe for disaster if you're unlucky.

I don't know how exactly things works, but zig approach is very nice, i wish it was possible with D too

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

I've heard before that there is a schism in the D community between two different options, but never can remember what it is. Something that fragments the ecosystem?

D's biggest problem at this point is that everyone (including me) vaguely remembers that period where it was in limbo between different design strategies, and consequently frets: "is it stable yet?".

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

> finally

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

I heard about this schism less than 5 years ago so there's probably some pages/blogs/talks that need to be updated.

It's mostly second hand commentary.

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

There were two stdlibs in D1 (the official one called phobos, and tango which had a more "java-like" feel). I haven't been following D for years, but it looks like Tango sort of died off when work on D2 started to get traction[0]

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

The api wasn't really the problem, it was more about the language runtime. Upstream wasn't exactly receptive to big changes, so a segment of the community forked and made the changes themselves. But since these hit the core language, it led to some incompatibility.

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".

Interesting. I guess that was all after my stint playing w/ D. I had never heard about this Amber effort until I googled for tango today, for example. From my perspective as a user, it definitely felt like the API divide was a problem - there were things that were only available on top of phobos and other things that were only available on top of tango and you couldn't use both together.

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.

See the api divide wouldn't matter if the runtimes were merged (this actually happened, you can still use Tango today if you like) since you'd just import the other modules and have them side by side. Sure some libs might depend on std.socket and others on tango.socket, but that's not a huge problem since they can exist side-by-side. You might just need an adapter if you wanted to pass a socket from one lib to another that uses the different thing. Slight hassle but totally solvable.

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.

Thanks for that context. I wish that information was more obvious and well-documented since it seems like enough people still don’t know the details. D does seem useful and it’s something I want to pick up someday but had been holding off because that situation sounded so demotivating.

What irks me is this stuff is all from before 2007 - that's when the runtime support lib branches were merged - yet social media comments make it sound like it is today.

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.

You might mean the D1 vs. D2 schism. That was ages ago, it hasn't been a live issue for a very long time.

IIRC there were two different standard libs at one point. I don't believe that's an issue anymore.

I've been in the D community since 2009. There is no schism.

There was a schism the best part of 15 years ago now.

D does have a package manager named dub, it works well.

https://code.dlang.org/

> it works well

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.

Is the lack of incremental compilation aproblem with dub or with D compiler in general?

It's a problem with dub. The D compiler operates basically exactly like a C compiler would as far as I'm aware.

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.

Both. Incremental compilation is possible to an extent, and reggae[0] does it. However, due to the semantics of d imports and templates, compiling a module will require at least cursory parsing and semantic analysis of all the modules it imports. Meaning that for a binary with a single entry point, modifying pretty much any module will require recompilation of the top-level module, which means there's a certain degree of incrementality you can never reach.

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

dub does incremental builds.

On a per-file basis? Afaik it works with package granularity, so if you change one line of a package, you're SOL.

Per-package translation unit are faster than per-file translation units.

One thing D does have in its favor over most of the competing alternatives is a fairly mature ecosystem story, with multiple implementations of the compiler, decent docs, libraries for common domains, and a lot of "use hours and eyeballs" on the project as a whole that have brought up and addressed obscure issues. While it has accumulated some more serious warts with time as the project goals have shifted in very large ways, D could be described as boring, useful, and mostly keeping up with the trends, which is a pretty decent place for a fundamental software development tool to be in. I'd be happy to use it again.

If LLVM languages are going to become more mainstream in the browser, you need more than a WASM backend - you need to significantly improve interaction with the UI from WASM.

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

Wouldn't the ultimate irony be "native" toolkits like Gtk and Qt being normalized through WASM code rendering to a canvas?

Qt already supports WASM, [0] but it's a long way from being 'web native'.

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