but the only ones that are considered to be harassers, or subject to moderation, are the non-members.

In addition, there is no visibility into does the moderation, how long it might take, what would be filtered, and for what reason.

Therefore the forum's use of moderation is at best, suspicious, and can easily become a tool for abuse.

There should be a record of who filters what, when, and why.

And this should be made public also (although people should not be forced to subscribe to them).

In any case, people are better of spending their time on stuff that is actually supported, and can get them employment.

You are astroturfing HN like you were impersonating people on the D forums. Please stop.

I did, not very intensively for now, but the general feeling has been good:

- I can use it from day one if I know C++, something to consider if you want to get things done

- it interoperates better than other languages with my C++ stuff

- the metaprogramming capabilities are nice and familiar to someone coming from C++

- the standard library is well prepared and the ranges, algorithms, named tuples and others are well-thought designs that have zero overhead (they use compile-time mechanisms for algorithm selection or tuple code generation)

- std.experimental.allocator: you can control memory management, though I did not use this myself and I do not know how mature it is

- there are efforts to make the language more gc-free friendly if that is what you need

- there is a switch for betterC that allows you to use a subset that is powerful yet still very light

- compile times are good

Is it complex? Well, it can get as complex as you want, but using it without being too fancy is joyful and easier than C++, definitely. I have been investigating several of these languages for a while, concretely, a bit closer Nim, Go and D.

Go is very nice at what it does, but that's it. It can be written and used in teams easily, but it is too specialized: by specialized I mean you have the GC with the channels and goroutines systems but you do not have control on memory layout or indirection or allocation AFAIK. Interoperability is also more difficult than with D.

Nim looks promising. The problem is that it looks promising, but the reality is that it is not ready for production use yet. Also, something that should look like an advantage looks like a disadvantage to me: it looks clean because it follows a Python syntax. D chose to follow C and C++. That is an advantage, no matter how clean Nim looks, because at the end, most people know C. The library ecosystem is far better in D also. Interoperability: I think Nim is easy to mix with C, but not with C++ and Objective-C. Do you really know of anyone that would adopt a language without a realistic migration path of their code bases? Maybe for hobby projects yes, but for enterprise? Because these things can get painful easily and they make for a lot of time wasted.

D: powerful and understandable metaprogramming if you come from C++ (I saw Nim's metaprogramming and I must say it also impressed me, that is true). Good migration path. More mature than Nim. General purpose, can control memory allocation. Trying to solve real world problems. The most pragmatic tool for general purpose programming if you want good performance and getting things done, something I care a lot, because at the end the language is just a tool. I do not need a perfect tool, I need something convenient that lets me finish things.

From this pack, for me, D is the only one that is a positioned candidate to be both general purpose and mature enough at this moment. Nim is not there yet, unfortunately, and interoperability and lack of maturity play against it strongly. If you add that almost anyone knows C and many people know C++, but many people will just not know Python, that is something else to consider. As for Go, it is too specialized in one area, which does very well. But it is what it is.