OCaml and Haskell build self-contained binaries, and have done for decades. OCaml has very fast compile times, and an ordinary C-like linking system. You can even directly link C *.o files. Go certainly isn't "innovative" here.

And if you don't need types, there's LuaJIT with all the dynamic features, best inline C FFI ever done, runtime performance in par with native compiled languages, and tools for producing self-contained binaries if needed - https://luapower.com/bundle

Rust is not an alternative to Go. Go is significantly easier to learn as it's very simple. Crystal and Nim come close but they do not have the backing of a large tech company and their ecosystems are not as mature.

There are much more robust and advanced programming languages with native code compilers, imperative programming support and decent code performance - e.g. OCaml.

Nim is another good alternative. Small, dependency-less binaries are one of its strong points.

There are many compiled languages with embedded runtimes. Haskell is among the best of them.

> haskell is among the best of them

There is little need for this kind of absolutism. Citing a haskell as one the best language in a contest where op ask about rust and c++ is dangerous.

To op : if your domain calls for modeling relatively 'type stable computation', and need strong correctness garanty, haskell is a great match.

How is it dangerous? Your qualifying remarks with regards to Haskell's domain make no sense. If you need a fast, compiled language with managed memory, high ease of development and a strong ecosystem then you can't go wrong with Haskell.

'Type stable computation' and a strong correctness guarantee are some added benefits of Haskell, though any strongly typed language (like for example Rust) will have these qualities.

A nice benefit of Haskell that most other languages don't have is that it is explicit about side effects which gives you some extra confidence in the behaviors of your code. Related to this is its unusually powerful type system, which allows you to make some abstractions for generic code that are not possible in most other languages.

Haskell's runtime has one overriding attribute: laziness. If laziness is not desirable in your domain, Haskell is not a useful option

FWIW, strictness may be introduced into haskell programs. Weak-head normal-form evaluation is builtin with the "seq" function and the "deepseq" library is commonly used for fully normal form evaluation of expressions.

GHC 8 also introduces the Strict and StrictData pragmas[1] which allow you to make a module (or its types) fully strictly evaluated.

[1]: https://ghc.haskell.org/trac/ghc/wiki/StrictPragma

Can you give me an example of a domain where laziness is not desirable? I only do Haskell for side projects, so perhaps I lack exposure to some domains.

Laziness can make it hard or counterintuitive to determine the runtime properties of your program, especially with regards to memory. Same with real-time systems. But you can turn it off, or force evaluation if needed.

Almost all static compiled languages have AOT compilation to native code, even Java and .NET ones, although many tend to ignore it.

So all the ML languages, Java, .NET, Pascal dialects, Modula-2, Modula-2, Oberon and its descendants, Ada, Crystal, Nim, D, Rust, Swift, Objective-C, ...

Definitely Swift,but is not as mature yet as the other options mentioned.