I'd say Scala probably, but it leans very heavily towards providing escape hatches that let you use it as Java++, so it's easy to write code with mutability everywhere. This isn't much of a problem if you're disciplined about it yourself, but scaling across an organization, it's very tempting to treat it as Java++ and use it as such.

You might want to look at Kotlin, though the mutability options aren’t as good as Rust’s.

Can you describe (or link) a scenario where more advanced mutability options would be preferred / better practice?

This article looks pretty good: https://blog.stylingandroid.com/kotlin-mutability/

I would describe the difference between Rust and Kotlin as: Rust offers control over interior mutability and guarantees that there is only ever one mutable reference at a time—Kotlin offers exterior mutability control, not all that dissimilar from final in Java or const in C/C++, but it is better.

Crystal has been very nice on a project at work. Ruby-like syntax but statically typed, compiled language so a lot of the things that bites ruby programmers don’t even come up. It’s what I was hoping Go to be, it feels clean. It beats Go in lots of benchmarks, loses in others.

I would second this. I moved from Go to Crystal. Crystal has been great to work with. Due to a rich standard library, the absence or fewness of third-party libraries may not be much of a problem, especially if you are looking for developing web applications and command line tools (two areas where I have used it). It also has a very friendly and helpful community.

Swift. Automatic reference counting still requires more developer attention (to break reference cycles) than a GC, but is still easy to get right. Too bad that outside of iOS development it's still unusable.

I agree with this assessment. Swift has a lot of the things that make Rust nice to work with, but favors usability over performance while Rust does the reverse.

> Too bad that outside of iOS development it's still unusable.

Sub-optimal for sure, but not unusable. It's being used in production on the server in several instances.

I have a swift web service running in production, it's definitely not unusable. You're right it's rough around the edges but it's early days.

D.

It's not based on an ML-ish type system, but the amazing metaprogramming capabilities allowed std.variant.visit (sum type matching) to be implemented in normal library code:

https://dlang.org/blog/2018/03/29/std-variant-is-everything-...

immutability is not default too… but on the other hand, there's @nogc and betterC mode, purity annotations, contract programming, C++ (!) interop, an option to use the "C-ish" linking model (to build with e.g. Meson instead of Dub, install dynamic libs system-wide, and so one), and again, just next level metaprogramming.

You can do anything with Rust procedural macros, but they give you a token stream and you drag in the rust parser as a dependency and operate on the raw AST. That's hard and "special". With D metaprogramming you can, for example, just `static foreach` over the list of the current class's members directly inline where you want it.

IMO, Rust + GC = OCaml.

I'd say D, but it has optional immutability. It feels like C++ with GC more than Rust.