> Does D have a thing?

Probably its most useful feature is rather subtle. It's very easy to express diverse ideas in code in D without having to resort to contortions. It's something people realize after having worked with D for a while.

It is not the result of having feature X (you can always find feature X in other languages or a way to make X work), it's the combination of various X's.

For example, some algorithms express naturally in a functional manner, some imperative, some OOP, etc. It isn't necessary to buy into a manner for the whole program, just use the manner that fits the particular part of the program.

You might like to use FP here and there, but don't want to deal with monads. You can use OOP for the AST, but don't want to box integers into an OOP class. You like dynamic typing for one type, but it's a bad fit for another. You can garbage collect for a quick prototype or a seldom used part of the code, and carefully manage memory for the release or the hot spots. (The Warp preprocessor I wrote did that. https://github.com/facebookarchive/warp)

There's a lot less time hammering square pegs into round holes.

I've seen more than enough presentations on "How To Do Technique X In Language Y" and everyone says how clever that is but the contortions are just too awful to contemplate.

The flip side is that D won't be satisfying to a purist adherent of any of those paradigms.

I really like how purity in D is so... practical. I like that a for loop is totally allowed in pure code as long as it modifies no data outside the pure block. One of the most annoying things in Haskell was to translate some algorithm that looks very natural in a for loop into some other sort of combination of map or reduce or something even more complicated.

(Yes, I know Haskell can also fake for loops more cleanly with monads, but they still feel awkward and unnatural.)

My recollection from the last time I worked with D was that pure could be more complicated and strict than expected when using standard libraries functions, e.g. using trigonometry sets hardware global state, thus impure. I don't remember if there was a good workaround to convey intent of purity despite that.

In D "pure" means "referentially transparent".

R is old. R always had math. That's not new. Python always had a lot of other things. Strange depiction.

I think you're a new engineer - R has always been math, from the bottom up. Python is the relative newcomer to math.

Go was exciting before Docker existed.

JS has the browser, and then had Node.

Scala has functional programming and the JVM. Spark is not really a "Scala thing" (although it is written in Scala). You can use other languages with Spark.

Tomcat is hardly the first thing that comes to mind with Java.

What a bizarre perspective you have!

JS has an actual write once run anywhere with an above-average async story.

Python was not popular because of maths. Python was very popular long before the scientific computing stuff. Python was chosen for that for two reasons: ease of extension using C, and being extremely easy to read and write.

There's a reason that Python is commonly referred to as 'executable pseudocode'.

But yes, Ruby had Rails, JS had web browsers, Perl made string handling easy, Java was appealing to managers (don't let your moron employees write undefined behaviour: CHOOSE JAVA!), etc.

I'm pretty sure Java's feature is that it has java.lang.NullPointerException