[otabdeveloper1]

What they have in common is a complex compile-time static typing system.

The source of complexity isn't a mythical "culture of complexity", the complexity is there because it's inevitable if you want to implement powerful compile-time type reasoning. (And you definitely want compile-time reasoning because it's the only way to guarantee performance and correctness of programs.)

The case of Haskell and Rust proves that the issue isn't cultural, it's inherent to the problem domain.

[the_af]

What exactly do you mean by "a complex compile-time static typing system"? I'm not familiar with Rust, but C++'s and Haskell's typing systems don't look very similar, or even of similar complexity.

I do agree there's an inherent complexity in the problem domain. It's just that some languages are more helpful than others in dealing with this complexity :)

PS: my own bias: Haskell's seems both easier (in general) and more helpful than C++'s.

[jcelerier]

> C++'s and Haskell's typing systems don't look very similar, or even of similar complexity.

yet they are. The difference between the Haskell type system and the C++ type system is that generic constraints on types are explicitely specified with typeclasses in Haskell, while they are implicitely specified with templates in C++ (though this changes in C++20 with concepts).

To make a "conceptual leap" beyond the C++ and Haskell type systems, you have to use a language with dependent types such as Idris or Coq (and actually, dependent types can be simulated in C++ ! http://pfultz2.com/blog/2015/01/24/dependent-typing/ but like all simulations, it will be slower than if it was implemented directly by the compiler).

[the_af]

That is not the only difference between both type systems. It's very different to use one or the other. Especially in practice.