Rust getting more of Haskell's type system features is a good thing. The stronger your type system is, the more mistakes you can discover as compiler errors instead of runtime bugs.
I used to think a stronger and stronger type system was a universal good, then I got experience with code written by architecture astronauts[1] armed with such type systems. Knowing exactly which kinds of things to make impossible at compile time and which not is absolutely an art form. Unfortunately, such type systems seem to result in so many nightmares.
The linked article talks about abstraction, and that you could abstract so much that the concrete problem doesn't fit in your abstraction. I.e., your abstraction is broken.
I think that is precisely why OOP started to disappoint (tbh: I also think many people did not understand OOP really well).
Haskell pushes you to compose types instead of building inheritance hierarchies. Multiple inheritance turned out to be a bad idea too, so yeah, OOP program do typically not have the best models of the problem domain they were intended to model.
At the other end of the spectrum you see people just give up: everything is a kind of dict or a string, or wo knows, null? Looking at you php, python, javascript..
All the improvements you see in todays OOP languages are ideas stolen from functional languages like Haskell. What Haskell could have done better is be strict instead of lazy by default.
To model the real world and make assumptions explicit, a type system, as Haskell gives you, is so nice.
I agree that you can make types also really abstract like some people indeed do. It's fine if you do that as a library author, but you should offer a facade with some simpler type aliases. If you stick to Haskell98 and possibly enable GADT support you already get an immensely powerful language.
Also, I have not used Haskell for a while, but I heard the compiler error messages have become way more human friendly these days, so that helps with complex types.
As with anything, it all goes well until it doesn't. When you have a single bug (e.g. type error or dynamic error), the guts of whatever is in the box spill out. Case in point: all the implicit template parameters to std:: in C++ these days. The only way to add configuration options in a backwards-compatible way was to add default values for template arguments. That's all fine and good when you can't see them, but as soon as you have a nasty type error, the types that come spilling out in error messages have zillions of default arguments that get printed.
It's almost always the same with inference. I would be very, very wary of doing so much type sophistry that it requires heavy inference to be usable.
at the end of the day architecture astronauts delegate pipe laying to plumbers, and the plumbers benefit from existing build plans created by architects with all their sophisticated tooling.
If a typesystem has any impact on the popularity of a language, then i assume rust doesn’t want to copy too much of haskell and needs to know where to stop..
There will always be more things that someone will want to formally verify that don't exist in the type system. How do you decide what is and isn't worth putting into the type system?
