What were the main issues you came across? What language would you prefer if you had to start from scratch and had the choice to go with anything else?
Rust used to have a GC in the past, as well as green threads and a bigger runtime. All of this has been explicitly removed before Rust 1.0. The reasons are well documented in many pull requests and RFCs for the language.
The way the async feature works in Rust is that the asynchronous function is just a syntax sugar that gets desugared into a state machine struct during compilation. The way this state machine works is similar to how one could achieve async in a language like C. It's unfair to dismiss everything as excuses given that the fundamental aim of the language is different.
In Rust async functions are not really colored because again - the async function is just a syntax sugar for a struct you can create and use in a sync context. The colors analogy is only really applicable in a language like JavaScript, where there's no way to poll an async function in a sync context.
Here's the thing though: Rust could have every function be an async state machine, automatically. And then the compiler optimizes away that code when it isn't needed. It would be a big pain to implement, but it's doable, and it would deliver a developer experience much closer to Go's. There isn't a technical reason for why Rust couldn't do this.
FYI you can't poll an async result in a sync context in Rust, either.
> There isn't a technical reason for why Rust couldn't do this.
First, it would be a huge undertaking. That in itself is a huge time/resource burden.
Second, it would add overhead to any non-async function call. Because async introduces branching on every function invocation, it would make the resulting assembly even harder to understand. This strongly goes against the zero overhead/ zero cost abstraction idea of Rust.
By the same measure, Go could technically remove (almost) all GC, add some kind of borrowing mechanism and steal Rust's thunder.
I personally think that writing so called "terse, clever" (misnomer) code, is not an issue with the language, rather the user. Do we really want to have worse tools, just because some people are writing bad code? Clearly it's an issue with the software engineering process rather than language itself. A good language should allow a skilled user to write code as clear as day, while properly modelling the problem domain and making incorrect states logically unrepresentable. We have a tool for that, type system and a compiler.
> Do we really want to have worse tools, just because some people are writing bad code?
People tend to write bad code. It's a fact of life. Tools forcing people who write bad code to write better code can't be worse tools by definition. They are better tools.
The fundamental issue is that humans contrary to machines will never know for sure whether whatever they do write is in fact correct code. One can think they are writing good and readable code, but that doesn't mean anything if the code is incorrect. And if you write lots of boilerplate that means more possible bugs. That's also why no one sane writes assembly (or increasingly these days C) unless they have to. We generally prefer more complex languages which put a constraint on the amount of possible bugs.
Sum types allow for more robust modeling of the API boundary in libraries, so in fact having a better type system is desirable even when "just gluing libraries", because it can make incorrect program states physically unrepresentable.
Whatever language you end up choosing, I hope it will be a memory safe one. Browsers' main purpose is to interact with the outside world, and they even have to run third party code (JS) all the time, so minimizing attack surface would go a long way I think
I think that pioneering the work of reimplementing web standards in not strictly OOP language will make the implementation easier for anyone else in the future, surely many of the problems exist by virtue of being done for the first time
