[arcticbull]

I'd love your thoughts on this, my guess is it's because of ergonomics improvements. Specifically, inferred types. This middle-ground lets you have much of the ergonomics of a dynamic language but with the safety of a static one. You may have to hint it from time to time, but for the most part (99%+) Rust guesses the types of everything I do day to day, and when it doesn't know, it ... asks.

[ajxs]

Inferred typing is just a feature of statically typed languages. Static typing just refers to the type of a variable being known at compile-time. Type inference is the ability of the compiler to infer the variable's type from the context of its declaration. It doesn't mean that there's any loss of safety at all, it's just a matter of syntax.

[arcticbull]

Yep, exactly; I was suggesting that the move in modern languages towards inferred typing is what makes statically typed languages pleasant to work in, which has lead to their return to popularity. Sorry if I wasn't clear!

[ajxs]

Oh, pardon me. I re-read your post and it makes more sense to me now! Maybe that plays a role. I more attribute this, somewhat in jest, to enough time having elapsed since the renaissance of dynamically typed languages began for developers to have gotten sick of maintaining codebases built in them. I also, very cynically, think that there's a very contrarian and competitive streak running through the development community which drives developers to always seek to move against the majority. Cultivating a kind of heroic self-assertion in the process. Think, for example, of the resurgence of interest in functional programming and the aggressive proselytisation on its behalf. In defence of my polemic assertion here, I have somewhat cultivated this idea around myself and my own shortcomings. Also, even when I program in languages featuring type inference I usually mandate that my team use explicit type declarations for the sake of clear declaration of intent and better tooling support, that's just one opinion there though.

[steveklabnik]

In some sense. I mean, type inference is not new. But the languages that really brought static typing to the masses didn’t use it, or only did deduction, so it is “new” to a lot of programmers.

I do think that there’s a relationship between power and usefulness, but more power isn’t always better. I’d rather use Ruby than Java 1.5, but I’d rather use Rust than Ruby. YMMV.

[typeliftr03]

It's kind of sad to me that (almost) complete type inference has been around since the [70s](https://en.wikipedia.org/wiki/Hindley–Milner_type_system) and it's still not mainstream. (unless you consider F# or OCaml mainstream languages)

[pkolaczk]

Type annotations at the signature level are documentation, so I'm not so sure if global type inference is really better than local type inference. Also HM type inference doesn't play nice with type systems with subtyping or method overloading.

[int_19h]

OCaml does have subtyping (albeit with a clear separation between that and implementation inheritance) and method overloading, but its type inference accommodates those. Or am I missing something?

[pkolaczk]

Seriously asking: How does it work for undecidable cases? Nominal subtyping may cause ambiguity where both supertype and subtype match. Overloading may cause ambiguity where more than one overload matches, and depending on the overload we can infer different types.

BTW I didn't say it was impossible, only that it doesn't play nice and probably is no longer a pure HM system. The search space is definitely much bigger with overloading and subtyping.

[int_19h]

It still has classes, and implementation inheritance with method overloading, but they're completely decoupled from subtyping (so e.g. subclasses are not necessarily subtypes - a class can use self-type in an argument position). And types themselves are structural, with row variables and polymorphism. If you need to define an equivalent of a named interface, you just define a type alias, like any other. And when you define a class, you get an auto-generated type alias for the structural type of objects that it will instantiate. [1]

End result actually looks surprisingly familiar to someone coming from C++ or Java, at the first glance. It's really a shame that it's not something that OCaml is famous for; it deserves to be. I wish I could have an object model that expressive in C#.

[1] https://caml.inria.fr/pub/docs/manual-ocaml/objectexamples.h...