an idealized language
On the syntax and semantics level it should be a modern ML.
In short, it should be Standard ML + Type Classes from Haskell (so Traits could be implemented, not the other way around (Type Classes are actually Type Traits!)) + compiler techniques from Rust + first class
select from Go with pattern matching everywhere, of course, so any code from Erlang could be easily tramspiled into it.
On implementation level it must be Go, of course. Just a straightforward compilation into native code +
stdlib as thin layer on top of target OS (ideas from Plan9/Inferno).
The Rust's principle that there must not be any underlying C-based runtime (with all C-related problems) is more a meme than a real thing, since a kernel is still C or C++ and an OS is merely a user-visible (or user-level) interfaces to the kernel. Inferno's approach is more realistic.
And that is it.
In other words - not the Ruby's way of bootstrapping Rust (out of best parts of C++), but the Go's way (well-educated and experienced engineers instead of passionate amateurs) and out the best parts of ML and Haskell instead of C++.
Abstractly, types form a separate so-called static environment in which each value (including functions, which are values too) is associated to a type (possibly more than one). This is very similar to bindings (association of symbols to values) in so-called dynamic environment.
Since types live in a separate environment, type-annotations should form a separate, distinct sub-language, similar to an embedded DLS. Haskell's type-annotation for functions is the best example. The code is not cluttered and the type on any values could be easily checked at any time. Erlang has evolved a distinct DSL for typing.
Types must be inferred and being annotated only when it is absolutely necessary (to assist the type-checker when it is unable to infer algorithmically the type by itself - recursive functions is the canonical example). Functions shall be annotated to hint for their semantics, but an inferred type could be easily looked up and displayed by an editor. No fucking C++ or Java generics ever again.
A real-world type system inevitably evolves the notion of higher-order types (or types of types) so an ideal language must have higher-order types (like higher-order functions).
Whether or not to have functions on types is an open question, but to have constraints (asserts) and qualifiers (
forall) on types is the must.
Not a better C