To run with part of this: I want a language that can truly do almost everything, everywhere. Start with a FORTH-like base of primitives that can have different implementations (usually assembly, but also, say, JVM bytecode), and then aggressively build a rich language and standard library out from that so most users just see "enable the full standard library and get all the batteries included", embedded folks see "enable the minimal subset of the standard library and it's still a nice language", and porting consists of "implement these 10 functions and the language works, implement these 25 functions and the whole stdlib works". Also, enough community/commercial support that it actually has those parts implemented for everything from ESP32 to AMD64 OpenBSD to aarch64 Linux to Haiku to....

> I want a programming language that can do a lot, from web, game and IoT,

So far, Rust...

> with type system like Haskell/TypeScript/Rust/Ocaml

Still Rust...

> and simplicity of Go

As long as that's ”for similar tasks” and anywhere outside of Go’s particular sweet spots, AFAICT, that's still Rust...

In terms of the languages you listed there, sounds like V to me:

https://vlang.io/

This sounds amazing, why there is no more traction for the language? What are the downsides?

It's not actually a standalone executable (for example, on Linux, it has a dynamic dependency on libc), but everything else about it seems accurate.

This is what Ada does.

A very strong type system, makes native binaries, has low level control, but it writes and reads super simply. Generics are at the module ("package") and function level, not at the type level, and can take other packages as parameters.

I'm curious, how would a language have a type system as complicated as those but also be as simple as go?

Specifically, what does "simplicity of go" mean to you

Use Ruby with Sorbet as a type-checker

I'm testing that and Sorbet is very far from being a nice experience right now. Tooling is somewhat broken. srb rbi gems often marks gems as typed ignore, which in turns makes constants unavailable.

My biggest problem is that it's not possible to represent "duck typing" (structural typing), which is core to ruby. So an object that is "callable" (a lambda with no args, a block with no args or an object with call and no args) cannot be represented, since the expectation is that the object includes some interface (module), not that it has a method #call