This is in spite of the fact that, semantically, both are exactly the same thing.
Semantics is not practice.
Rust is a compiled language. All Types/TypeClasses have to eventually be resolved down to concrete structures/tuples that can be statically or dynamically dispatched too, and in most cases allocated to the heap/stack.
Haskell is NOT a compiled language. It compiles to a bytecode that is ran by the RTS (Run Time System) a ball of ~50,000SLOC in C/C++. Haskell TypeClasses are MAGIC managed by the run-time. They are not resolved to actual machine code. A compiled Haskell program is just the bytecode+source code+compiler+RTS bundled into an ELF. Yes some Haskell is translated into pure C, but all of it can't be. The pure C Haskell still depends on the run time heavily. Especially for managing type class dynamic dispatch.
> All Types/TypeClasses have to eventually be resolved down to concrete structures/tuples that can be statically or dynamically dispatched too, and in most cases allocated to the heap/stack.
My original remark was strictly about surface syntax issues (verbosity). Surface syntax is handled by the compiler's front-end. I have no idea why this should affect the compiler's backend or the runtime system. But maybe you know something about compilers that I don't.
> Haskell TypeClasses are MAGIC managed by the run-time.
No. Haskell's type classes and constraints are typically implemented as vtables (although Haskellers normally call them “dictionaries”) and extra function arguments, which are resolved at compile time. (With higher-rank types, the compiler can determine that a given vtable has to be passed around between places, though.) The runtime system has no special support for type classes - a type class instance is a record (of methods) just like any other.
Of course, Rust monomorphizes generic functions, and optimizes away the intermediate step of fetching methods from vtables whenever possible. But if you use trait objects (akin to Haskell's existentials), vtables will still be there.
Haskell is a complex hybrid. TypeClasses can't always be resolved to concrete statically sized types, Haskell does RTS Magic for you when this happens. Rust throws a compiler error in this case.
Implementing an abstraction that requires indirection at runtime does not traditionally render the language "not compiled". Any definition of "not compiled" that includes the vast majority of real-world C++ is not a definition in common use.
If you want to point out that "compiled" really ought to be a continuum rather than a binary property, and that by this definition Rust is "more" compiled than Haskell, I'll be right there with you (though the pre-existing word "static" probably fits better), but we'd be creating an idiosyncratic definition not shared by very many people. (Though perhaps it should be. The binary distinction of the ~1970s really isn't that useful anymore, in a world of scripting languages, JITs, and a greater focus on the costs of indirection.)
Haskell type classes are by no means magic and the run-time does absolutely nothing with them.
Type classes are de-sugared in the compiler and turned into an extra function parameter that is a record of functions, aka "dictionary".
This is a bit similar to vtables in C++, but different because firstly, the C++ vtable is already reachable from explicit parameters/implicit "this", and secondly, C++ actually has dynamic dispatch whereas type classes are not dynamic dispatch, at least from a language point of view - they essentially correspond to "overloading" in C++.
Type classes could just as well be implemented by expanding all invocations of the function with different instances and generating monomorphic code for every combination of instances. Compilers don't do that because it would waste too much space.
Also, what exactly is a "compiled language"? The words don't mean much of significance.
> This is a bit similar to vtables in C++, but different because firstly, the C++ vtable is already reachable from explicit parameters/implicit "this"
Rust vtables aren't attached to all objects, but they're always attached to trait objects (whose methods are dynamically dispatched). So it's halfway between C++ and Haskell in this regard.
FWIW, I would call dictionaries “vtables”. C++ and Rust just happen to impose restrictions on how vtables can be used, so that each trait object can be bundled with its own vtable (`exists a. C a => a`), rather than potentially bundling several objects with the same vtable (`exists a. C a => T a`). But this doesn't mean that Haskell uses a fundamentally different implementation technique.
> Type classes could just as well be implemented by expanding all invocations of the function with different instances and generating monomorphic code for every combination of instances.
Rust is a compiled language. All Types/TypeClasses have to eventually be resolved down to concrete structures/tuples that can be statically or dynamically dispatched too, and in most cases allocated to the heap/stack.
Haskell is NOT a compiled language. It compiles to a bytecode that is ran by the RTS (Run Time System) a ball of ~50,000SLOC in C/C++. Haskell TypeClasses are MAGIC managed by the run-time. They are not resolved to actual machine code. A compiled Haskell program is just the bytecode+source code+compiler+RTS bundled into an ELF. Yes some Haskell is translated into pure C, but all of it can't be. The pure C Haskell still depends on the run time heavily. Especially for managing type class dynamic dispatch.