Rust and Go are very different and I feel people want a middle ground that just doesn't exist currently.

A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc.

Syntactically, Gleam and Kotlin come somewhat close but not really. I like Rust but I do believe it is too complicated for many people who are capable of creating something but are not CS grads nor working as programmers. If you're only gonna use the language every once in a while you won't remember what a vtable is, how and when things are dropped etc. I understand that "the perfect language" doesn't exist but I think both Go and Rust brought amazing things to the table. I can only hope someone takes inspiration from both and creates a widely usable, simple programming language.

Kotlin is interesting as a middle ground, but I still find it much less productive than Go for most tasks, and unsuitable for tasks where you'd reach for Rust.

In practice, Kotlin is extremely complicated, and you end up spending time being clever. There are 1000 ways to do things. Operator overloading. Proxies. Properties. Companion objects. Exceptions AND result types...

The build system (assuming you use Gradle) is tantamount to torture for anyone used to "go build".

The coroutines APIs feel simultaneously more complicated and yet more restrictive than Goroutines. More structured but less flexible and more effort to use.

Access control feels awkward. There's no way to make a type package-private -- it's file-private or available to the whole module. This leads to either a larger API surface than desired, or the inability to break up complexity into multiple files.

Kotlin/Native and Kotlin/JVM really are two different beasts too.

Kotlin/JVM is mature, but then you are running on the JVM, so that cuts out a whole class of use cases you might bust out Rust for.

There is a very weak ecosystem for Kotlin/Native, and it's poorly documented. There are some scary bugs in the bug tracker.

You can't publish source-only libraries for Kotlin/Native either, so you need a complex CI setup to build binaries for every OS and arch under the sun. Or just don't publish libraries at all, which probably feeds in to the weak ecosystem...

Imho, most features of Rust that people would like to see in Go would still fit into the "concept" of Go. Just like they added generics, they could add just three things: A generic container for errors (Result), one for saner Nil handling (Optional) and a small sprinkling of syntax sugar to make these comfortable to work with (something like an elvis operator equivalent).

Go has the one big advantage that is almost solely responsible for it's success: It was created and directly used by a giant company that could afford to create amazing tooling around it and develop great opensource libraries for it. Already being in use and having libraries feel like the biggest determinants of a languages success.

So here is my take on this, once again:

Start with JavaScript. The basic syntax is delightfully direct, it has massive adoption already, the ecosystem is large, the runtimes are getting better all the time, compilation is here with WASM,

Now remove the weird parts (e.g., too much flexibility to redefine things, too much use of the global scope, too much weirdness with numbers, etc.), and add:

- Types (including sum/product types, Result<T>, Maybe<T>, decimals, etc.)

- More functional features (everything-is-an-expression, pattern matching, currying, etc)

- A comprehensive standard library.

Already this starts to yield a language that has the best chance to be what a lot want.

The other major advance in developer tools that I'm wanting to see is revamping HTML to have proper sophisticated controls built-in, controls that can be easily styled with inline CSS. This will reduce the amount of JS needed on the client.

These two things will yield a massive advance in programming productivity, at least as far as web-related development is concerned, IMO

(author here) in which ways does Gleam come short of that? Because I'm also looking for that middle ground and I was very curious to get a look at Gleam.

There is Crystal and Nim. With especially Nim, there is GC and generates c in the end.

> A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc.

Swift.

I think Inko (https://inko-lang.org/) has the potential to be that language with some tooling/adoption/maturation

> A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc.

You just described Ocaml and ReasonML (which is Ocaml with Go-like syntax).

> A garbage collected relatively simple language that compiles into a statically linked binary and has a [good] type system

Yeah! Pattern matching too. What are currently available languages closest to this? AFAIK, Gleam relies on a virtual machine, but otherwise seems promising.

> A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc.

So OCaml then (ocamlopt to do native code compilation)

Try F# with the new AoT compilation option and publish single file switch.

> people want a middle ground that just doesn't exist currently

https://borgo-lang.github.io/

Rust syntax, compiles to Go.

C# and F# will be by far the closest. Other options lack sufficiently good type system or tooling to match either of the two.

Compile to static native binary with 'dotnet publish -p:PublishAot=true' (or add this property to .csproj to not specify on each publish). In the case of F#, you will need to use Console.* methods over 'print*' because print has unbound reflection inside for structural output on "%A" format specifier (it will work most of the time but negatively impacts binary size and causes the compiler to complain).

I can especially recommend F# as "easier more business-focused Rust alternative" because it is expression-oriented, has discriminated unions, full HM type inference and gradual typing is a joy to work with. Data analysis and domain modeling are very pleasant to do in it too.

For systems programming C# is going to be the option to use - it will give you great concurrency primitives, fast (sometimes even zero-cost) native interop, smaller than Go native binaries and a lot of low-level APIs including portable SIMD. Go is often poorly suited for these tasks or can't do them at all (at least without workarounds). There are many new high-performance libraries focused on this domain as .NET gains popularity in non-gaming communities in this area. And of course you benefit from a huge existing ecosystem and won't have to do the all the heavy lifting by yourself unlike in niche languages suggested in sibling comments.