Came here to say exactly that. And despite my comment’s redundancy i’ll say it again. I love this language. Straight to the point, easy to learn, read and write. I wish it gained more traction.

Writing both boring and interesting finance code is very nice in D. The contract programming in particular catches dumb mistakes very quickly.

D is my favorite language, I enjoy using it a lot. Out of curiosity, when you say community support is lacking, what do you mean? So far my experience has been that everyone in the community has been very helpful and eager to help when I've asked questions.

> when you say community support is lacking, what do you mean?

I look up how to do X, find very few resources, more than half mention D1. Compare that with looking up X in Rust or Python, how many mention Python 2 or Rust before the editions.

I never recall anything mentioning how to do something in D1. Just ask on the forum, people are usually willing to help.

I think he's talking about the lack of a bigger community than lack of help.

Has the whole 2-library thing been fixed? Years ago when I got into it, it got really confusing and unsexy.

> Has the whole 2-library thing been fixed?

If you're talking about the whole Tango/Phobos (2 std libs) thing, it's fixed and Phobos won. But now there are optional function attributes such as @nogc (checks that the code doesn't trigger the GC), @safe (memory safety checks) and nothrow that's causing a bit of a problem.

For example, not all libraries are @nogc. So if you want to use some library in your @nogc code and the library is not marked as @nogc, you can't use that library. This is not as bad as the two standard libraries problem but it restricts the libraries you can use.

The attributes are optional like I said, you can just ignore them and write code that uses the GC (not @nogc), code that is not explicitly checked by compiler for memory safety (not @safe) and code that throws exceptions (not nothrow).

Of course this is sort of expected in multi-paradigm languages, like some people disable C++ exceptions. But in D's case it feels like the compiler and library developers' efforts are spread thin.

The main issue with the nogc and nothrow flags is people taking a feature designed for careful consideration, and using them for building from-scratch code with often no philosophy other than a vague and usually completely unfounded mental model where GC == slow.

Write the code first then measure it.

Agreed and I actually don't really care about the GC speed. I mostly use arenas / object pools and you can do that with or without GC.

Sort of undecided on the exceptions though. The Result / Option type in Rust is pretty nice to use (and !?*T in Zig, which is nicer if you ask me). It forces you to handle exceptions explicitly which is pretty nice and you can be sure there is no overhead introduced by the compiler for handling exception stuff.

I'd probably wrap all the exception throwing functions in my D codebases with Result type if we had language level support for sum types and match syntax. I know we have it in the standard library, I want it in the language with nicer syntax.

I also want the GC to be replaced with deterministic destruction using RC + ownership analysis and optimizations like Lobster does, but that's wishful thinking territory.

Even if it's small, the Option/Result style exceptions always have overhead in at least a limiting case whereas the unwinding style exceptions are basically zero cost with a modern compiler - the debt is paid in the implementation being tricky.

> unwinding style exceptions are basically zero cost with a modern compiler - the debt is paid in the implementation being tricky.

D doesn't return values when an exception is thrown as far as I know. How are exceptions' costs are paid by tricky implementation?

I thought exceptions require allocation and run-time type info and therefore always introduce some cost (this goes for D and C++). I guess returning values and allocating error strings statically can help with that (or maybe allocate some exception buffer on program start -- but that's technically "overhead"). Am I wrong, or missing some important context related to exceptions?

If you don't throw there's no overhead, hence Exception-al cases only. The Optional style always has an overhead but the cost of actually throwing is much less.

Lots of people do statically allocate their errors now.

Implementing stack unwinding properly is not trivial.

It's crazier even when you consider how insanely fast the official D Forums render. I'm going to go out on a limb but I kind of doubt Vibe.d is plastered with @nogc everywhere. I am looking forward to the borrow checker being added to D on the other hand, that ought to be a little more interesting.

The official forums don't actually use vibe.d. vibe has the most marketing out of the D web frameworks, followed by hunt, but there's actually a few more too that just don't get as much attention, despite being older and possibly more widely used behind the scenes! The official forum uses the `ae` library. (And I have to mention my own `arsd` library which I'm pretty sure is the oldest web lib - mine dates back to 2008, but ae's pretty old too so he might beat me, and mine actually does better on some benchmarks despite me using GC and such with wild abandon.)

That said though, yeah, I don't think any of them use `@nogc`. I've actually tried to get the gc to interrupt audio code before and couldn't even hear it. I'm sure a bigger heap to scan might cause a problem in some situations, but these fears are really overblown in the popular commentariat.

Agreed. @nogc is useful if you have no a disabled or no-runtime, or in tight loops. Other than that, it's more fruitful to use pools, benchmark the GC, keep scannable heap small.

Is the phobos standard library gc free ie @nogc ? Stuff under std.range, std.container, etc ?

Parts of it are `@nogc`, not all of it. You'd have to check the documentation for each function you want to use (or write `@nogc` code that uses the std and see if the compiler complains I guess).

Yes it has been fixed since 10 years.

Same. I really respect Walter, liked the language, but the tiny community seemed fractured already and a future unclear.

Will definitely revisit when things settle.

The Phobos/Tango thing has literally been settled for basically 10 to 13 years now.

Beyond that D is a good language for writing software in. all language communities have fractures unless the language attracts lots of either new or bad programmers who haven't formed opinions yet

Things settle? Sheesh

I'm in the market for a new compiled language. Rust seems obstuse. I was toying with picking up Go but haven't committed yet. I want to write a Roguelike. I'm here and listening to you. Sell me on it.

The BindBC family of libraries gives you dynamic & static linking to many game libraries: https://code.dlang.org/search?q=bindbc

You can start your D usage with these examples: https://github.com/p0nce/DIID

I don't know the status of https://code.dlang.org/packages/libtcod-d

In game communities, there are lots of developers who spend time inquiring and researching about game writing platforms (languages, libraries, engines) but end up writing nothing. So a developer expecting somebody to "sell" them a language in order to write a game, will likely end up writing nothing.

"Rust seems obstuse" doesn't mean anything. On the other hand, I personally think that Rust is not the most productive language, overall, for game development (I'm familiar with Rust gamedev). This consideration includes the hard truth that as of now, the game libraries are young and buggy.

In an theoretical world, where all the languages have stable and equally functional game libraries/engines, in my opinion, the most productive language is something with deterministic (manual) memory management, but less memory safety (=overhead) than Rust, but that is still safer than C-family languages. I can picture D fitting this characteristics, but also other modern languages. This does not apply to areas where where safety is paramount (e.g. networking).

An excellent and considered reply.

When I say that Rust seems obtuse, I mean I've been bashing my head against its philosophy and syntax for some time without reaching the magic "hey this works and I'm suddenly productive" summit (or at least plateau).

I've come to the conclusion that it's not for me, but my interest in it stemmed from frustrations with Python and my memories of enjoying writing 'C' in the 90s. I find C++ a language without an underlying philosophy and seems like a horrid patchwork of things; Java is frustrating and verbose. C# is very Windows centric, which I'm not adverse to exactly, but I don't run it. Various other languages I've thought about and discarded.

I was toying with Go as that seems to have many fans, and seems to have wheels, but I'm cautious given some of the criticisms it comes under. D was not on my RADAR, but now I'm quite interested and probing its good and bad points. It looks promising on a casual look.

You're right, of course, "lots of developers who spend time inquiring and researching about game writing platforms (languages, libraries, engines) but end up writing nothing. "

Most people come from the point of view of they enjoy playing games, so they think they would enjoy writing them. Same with reading novels/writing them, and probably many other spheres of human creative endeavor.

I'm not saying I'm immune from this kind of thing, but my ideas are very modest, and if I fail to implement my game, no harm will come from it; the opposite in fact, as the very act of solving programming problems is as productive as solving a crossword puzzle, and will serve, if nothing else, to keep my mind sharp (as my current job requires no programming ability whatsoever).

I don't enjoy playing games, I'm tremendously bad at them and so don't get much positive re-inforcement on them as an enjoyable activity. But programming is fun, and that's what I'm looking for.

Dart is also an option.

https://github.com/munificent/hauberk

https://journal.stuffwithstuff.com/category/roguelike/

I played with D quite a bit, and really liked its syntax, perhaps apart from the fact that you start with the type in declarations, which IMO is a bit detrimental to visual scannability.

Anyways, the strong concurrency story in Go finally bought me over there though.

I still miss the super readable (almost python-like) syntax from D though.

I quite prefer types on the left. The name of a variable expresses hope about its use and purpose, but the type is a definite statement about what the behaviour of the object is. I've used both and really prefer left types.

Lack of structured concurrency is the reason I stay away from Go

You can almost always use `auto`, which might help for a visually more pleasing experience...

What makes it a better language than C and Rust? What is unique about it?

Lack of bullshit in the source file.

Unlike some D programmers I don't mind rust but compared to C and C++ the primary difference I'd say is that D has a lot of features that you'd have to emulate with either macros or recursive templates that means that the source files end up much cleaner.

If you want to declare a struct with N members where N is declared at compile time, in C++ it's usually a question of doing a bunch of compile time magic that leaves a roadside picnic of SFINAE everywhere whereas in D it's just a "static foreach" loop inside a template.

Out of all the new shiny low-level languages, people seem to praise its strong compile-time metaprogramming facilities. Though the compile-time execution engine in D is still a tree-walk interpreter (very bad performance/memory usage), unlike in Nim and Jai where they use a much faster bytecode interpreter for the evaluation.

The compile time execution itself is just one piece of the puzzle, the other two being compile time reflection (which I think is actually the key piece) and the built in code generation.

Running functions alone is not that interesting, and neither really is generating code. You can do those (arguably better for some cases) with helper programs as a separate build step. But reflection is non-trivial to do externally, so that's the biggest value add, and using it with all three pieces let you close the loop.

Agree with this, Zig and Jai seems to be the most ergonomic in this area (types can be checked and manipulated in compile time as easy as values in runtime).

But what I’ve mentioned is also very related to the ergonomics of compile-time metaprogramming, since these techniques are all useless if it severely increases builds times up to the point that developers have to use it sparingly. Only Nim and Jai has fully gone the route of using a bytecode VM for compile-time evaluation, while D had a similar project back in 2017 that was abandoned, and for other languages (C++, Zig, etc.) it’s still in the planning stage.