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.

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...

Don't forget that it's made by someone trying to sell you an IDE!

(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.

IMHO it's just that it's a beam VM language, which is a fatter runtime/ecosystem than is really needed to achieve the goal stated above can bring it's own bag of problems (but also it's own superpowers).

Also to be productive you have to utilize the rest of the erlang ecosystem, so at least some superficial knowledge in elixir & erlang is helpful for for some use-cases.

Syntactically I actually don't think it's that for off, but I dunno what GP was thinking, maybe that it leans more into functional patterns & sugar for those whereas rust/go can also be used in a procedural style. (Though at least personally I am using way more functional patterns in rust than I expected)

Trying to come up with a reply made me realize something. I was initially going to write something like "it's just not ready yet" but paused for a moment and reflected on that. That's actually not a real reason why it would come short of that. And instead of talking about how something "is not quite ready yet" we can instead choose to invest into it and use it anyway, with the goal of contributing and helping make it "ready" and more widely used.

Out of everything mentioned, I think Gleam is the most likely to succeed and what I think I will invest in as well. But that's not just because of the language design but rather because of their approach to community and community building! It's a very very nice extra that the language/syntax also happen to be what I like and have described in my previous comment.

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

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

I love Crystal, but the lack of a proper LSP and tooling makes it hard to just jump in and adopt for bigger projects.

Unfortunately, Nim's BDFL is... not known for playing well with others. Perhaps the Nimskull fork will grow into something widely useful?

https://github.com/nim-works/nimskull

That's total BS btw, I've been part of the Nim community for over 7 years now and never had an bad interactions with the project's lead. But I did witness behavior from certain individuals that was out of line. Some of them went on to blame Araq in other places, I have read their criticism, which I found very hypocritical. You should take their views less seriously.

> 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).

Last time i tried to install ocaml on windows few months ago i failed to do so, it's a well known thing that it is not 100% supported on windows therefore it wont have the adoption that go/rust has (as it's been the case forever now)

This doesn't count because the idioms are very different from Go and Rust. And I suspect there's a high learning curve for features like Functors.

If you check the Wikipedia page for OCaml to find out where it gets used, you'll see why it's ocaML. That is, you'll notice that it's mostly a MetaLanguage, or a language for writing other languages. The same observation applies to other languages in the ML family.

> 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)

> 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.

If they'd drastically improved their tooling then yes.

But sadly it's not that easy to create a statically liked binary in swift. The last time i did it it also included the whole runtime, and the resulting "hello world" binary was 50mb large. Annoying at least.

For years I wished they got their stuff together, but at this point I'd be very suprised. They probably have too much technical dept already due to the support of XXX edge cases Apple need for iOS/MacOS development.

> For years I wished they got their stuff together, but at this point I'd be very suprised.

This is a thing that's having work done, but still too large depending:

https://www.swift.org/documentation/articles/static-linux-ge...

See here for sizes of various languages as of August 2024 when I'm commenting, but this is Swift 5.10 for Windows:

https://github.com/MichalStrehovsky/sizegame

Build actions here:

https://github.com/MichalStrehovsky/sizegame/blob/master/.gi...

What you want, instead, is Swift 6 for Linux, while e.g. Alpine, as of summer, still too large:

https://mko.re/blog/swift-alpine-packaging/#:~:text=Package%....

In this thread on Swift for AWS Lambda, a dev gets a Linux static build to 5.9 megabytes:

"Then, I stripped it and it's now 5.9Mb. That's an impressive 86% reduction. Given that musl libc.a is 2.4Mb and libc++.a is 10Mb, I find that 5.9Mb for an executable that contains both libc and the Swift runtime is not that bad :-)"

https://forums.swift.org/t/aws-lambda-functions-and-the-linu...

> They probably have too much technical dept already due to the support of XXX edge cases Apple need for iOS/MacOS development.

See also embedded Swift:

"Apple explains that Embedded Swift is a subset of the Swift programming language with a much smaller footprint (the binary can be around 10KB..."

https://www.cnx-software.com/2024/06/13/embedded-swift-esp32...

Good that they work on it. And the efforts to refactor foundation into smaller modules go in the same direction.

I continue to root for them but they need so many improvments to be a realistic alternative to python/typescript/go/java for regular backend development.

At least in my field where we need to sure that other developers can continue the development without much hassle.

Just as an example, with those languages it's almost trivial to setup a basic projekt with dependencies. In swift however, it takes careful reading ot the swift package manager documentation to understand their concept of "products", "targets", etc. And I'm pretty sure i'd have to start from zero when i use swift for the advent of code in a few days.

There are many problems with devepdencies in Python, or package.json/gradle files. But at least they are (almost) foolproof to get started.

> relatively simple

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.

> 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.

Stretching 'currently available' a little, there's Roc lang [1]. Though still in development, you can use it for small personal projects. Another caveat is that it's a functional language, which could potentially hinder its wide adoption

[1] https://www.roc-lang.org/

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.

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

I think this is a really wise take, and one that I honestly haven't seen before. I would certainly try a language like this.

The one thing I would add: Provide a well-trodden path to easily drop down into Rust/C/C++ for performance critical functionality. I have found this to be a big point in Python's favor over Go; you can write things the slow way (ie. executing in the Python runtime), then profile and figure out where to push things down into an extension. Often you're doing something that already exists in a library like numpy or pandas or polars, but if needed, you can write your own extension.

Does WASM enable FFI on its own?

I think here you're pointing at something along the lines of Roc/Gleam?