Add in a static typing, type inferencing, and type checking, and that all becomes much more complicated, at least from this learner's point of view. From how highly upvoted my comment is, I suspect I'm far from being alone here. Learning, understanding, and implementing Hindley-Milner by itself was harder for me than learning how to put together a basic interpreter for a simple scheme. And I think a big part of that is the dearth of learning materials for things like Hindley-Milner and related concepts, whereas there are 100 books and tutorials on how to implement a Scheme interpreter in language X.
Finally, if you're talking about language performance, then yes clearly it's much harder to squeeze performance out of dynamic languages. But I'm talking about learning exercises here, not production programming languages.
dearth of learning materials for things
like Hindley-Milner
[1] L. Damas, R. Milner, Principal type-schemes for functional programs.
ex:
map : ∀α ∀β ((α → β) → (α list → β list))
[0] - Former C# language designer, Roslyn compiler team, etc.
https://www.reddit.com/r/programmerchat/comments/37qwmm/i_am...
The thought that somebody would not be able to understand the type of map had not occurred to me, because I'm surrounded by people with a strong maths/FP background. Shows just how narrow-minded I am.
- How to ensure that the inference algorithm is correct.
- How to design typing systems that are expressive, yet lightweight, and have enough type inference to be usable in practise.
- How to deal with concurrency and parallelism.
None of these problems is really solved. In practise even making type inference fast is a challenge, e.g. in older versions of the Scala compiler, type inference was really slow due to implicits.
If you're focused on benchmark numbers, dynamically typed languages are much more challenging to squeeze performance out of better code generation.
You can also add static type inference and consistency checking to a dynamic language, and indeed some systems do in the name of better