Thanks in advance to all who answer.
Edit: Add the "Ask HN" prefix to the post title.
It's still a bit awful and lacking most of what I want to support with it, but even in early days, it feels promising.
Was working on a small 2D game engine earlier, but got snagged on that working with OpenGL was so horrible generally that I figured I could utilize D's metaprogramming abilities to well, improve the experience. (got inspired by rust's glium)
Hopefully I'll actually complete it.
Terminals can be re-arranged using drag and drop both within and between windows
Terminals can be detached into a new window via drag and drop
Input can be synchronized between terminals so commands typed in one terminal are replicated to the others
The last one reminds me a bit of kibitz, a tool written using Expect (IIRC), that I had tried out some years ago, on Unix. I think it allowed you to have a sort of session with a user on another computer, and if you were in say vi, they would see the same vi screen on their machines, and your changes as you made them - something like that (like screen sharing on Skype nowadays, but this could have been there from before Skype, Hangout, etc.) Might not be quite correct about the description of what it did, since I only used it briefly and some years ago.
Was featured on the D Blog: https://dlang.org/blog/2016/07/07/project-highlight-auburn-s...
For the web backends I always use vibe.d
MUDs are the original MMOs. Zork but over the network.
D is a good fit for this because it simplifies my programming model. A MUD is typically heavy on scripting (or at least, it is if you want it to do anything interesting). These scripts need to be lightweight, since I might have one script instance for every player (to handle automated combat behaviors), several for each NPC, and even some rooms and items have scripts attached.
In order to simplify script writing, I want to be able to write my scripts in a simple, procedural way that lets me pretend that my current script is the only thing running. That means fibers. Not just fibers, but fibers that I have a fair bit of control over.
What languages have fibers? Not many. C/C++ have library support, but that means manual memory management and plenty more pain. Go's fibers are too opaque -- I want to have a watchdog that can ensure that every mob has an active behavior, for instance, and I want more control over scheduling. Mono used to have working continuations, but that was a long time ago, and they don't work anymore, as far as I can tell. Ruby and Python have fibers, but without static typing, I write code that is less reliable, containing more errors, that is harder to reason about.
https://github.com/dhasenan/subtex -- doing to LaTeX what BBCode did to HTML.
I write. I want to create ebooks from what I write. Previously, my process was: write in LaTeX (primarily using a double handful of macros instead of using LaTeX builtins), use htlatex to produce HTML; use a script to inline CSS rules to work around a calibre problem; use calibre to generate the ebook. Four seconds total for a 75k word book, and it vomited a bunch of temporary files everywhere. I could do better -- primarily by doing less.
Initially the benefits for using D came from Pegged, an easy-to-use parser generator; that sped development enough to make me happy working on the tool. However, Pegged was relatively slow -- it dropped time by only about 20%. At first I thought it was my ebook generation code, so I changed it around to be more allocation-friendly and faster. This was trivially easy to do in D. But that had no effect on the execution time.
I looked into it a bit closer, and it turned out that the Pegged parser was taking almost all the execution time. So I shrugged my shoulders and wrote my own parser. It was shockingly easy.
One specific thing I wanted to do is figure out, when there's a parse error, which line and column it's on. Normally that means keeping track of line and column numbers during normal processing, which is quite annoying and gets in the way of everything you want to do. But it turned into about three lines of code in the end, without interfering with normal parsing. Similarly, it's usually a bit of annoyance to keep track of where you are in the input. D's array slicing again made it trivial -- I just maintained a slice of the input string representing the part I hadn't parsed yet. No off-by-one errors. No segfaults. No array bounds errors. It worked the first time.
Nothing I couldn't do in another language, but D puts it all at my fingertips.
That ebook that took multiple seconds with LaTeX? 0.04 seconds with Subtex. I had to double check to ensure that it actually ran the first time after I got my parser working.
My experience with D has been mostly positive, aside from missing libraries. But that's getting better with time.