I honestly find it so annoying when return types aren't annotated. It's considerably less overhead for me when I can look at the signature and see the return type, even if a few characters are added.
I'm not sure I understand, could you elaborate more?
Can’t speak to its quality, but there’s nothing stopping someone from writing a repl from a sufficient compiler API... and “good” is only limited by inference quality and runtime performance. IDEs are pretty snappy at showing you autocomplete as you type regardless of whether the language has a garbage collector. And performance - well, that’s what caching would be for, and an optimized compiler design that only needs to recompile changed code...
I would also point out the “auto” keyword in CPP likely saves folks a lot of typing ;-) I know it and similar inferences changed my mind on the whole static vs dynamic debate...
If I didn’t declare the return type then the function will silently now infer the return type to be “string | number” (which might or might not break compilation elsewhere).
So I think this is more of a tooling issue, do keep in mind global type inference is really handy for interactive programming in the repl and short scripts.
Type inference
One thing that I'm fascinated and terrified by is the global type inference.
Doesn't it get really hard to figure how how you're allowed to call things?
Does it make your IDE experience slow? Similar to one of the things mentioned in the OP, I would think that the type hints would be super helpful to the compiler/analyzer.
As I mentioned earlier it's a powerful feature, and has its uses, especially when you are still trying to figure the types of your program.
For an easier taste of global type inference you can try elm language, it's also a good stepping stone to learning haskell
Types are a subset of contracts. Contracts are best explicit at the API boundary - which is to say, on exported functions and members of exported classes.