It looks like it addresses some of go, including:

- a better type system, that includes union types, and makes types non-nullable by default

- pattern matching

- designed with generics from the beginning

- try/catch error handling. This is controversial, and some people like checking every return value for errors, but it is a common complaint about go

- it looks like it is meant to have better c interop than go

Feels to me like it is Go++. Or may be Go+ / BetterGo.

And in a very good sense.

vlang is a Golang-like programming language. I will use vlang as an example,

v has the same syntax as golang and is derived from it. But otherwise, v is moving closer to rust, with immutability, bounds checking, and so on.

Here's a discussion of vlang's implementation of coroutine https://github.com/vlang/v/discussions/11582 Until recently, vlang has not supported coroutines very well

The syntax of nature is different from golang. But everything else is the same as golang, including goroutine, GC, channel, cross-compilation and deployment, and even free programming ideas, less is more, and so on.

I think these features are the best thing about golang, even in front of all programming languages. That's why I'm trying to see if I can create a better golang.

In the early stages of availability, I would not advise others to switch to nature, as this would be irresponsible. When nature is sufficiently advanced, the situation will be different.

Those design decisions by Go are what caused the need to trampoline to C right? How does nature fix that? Does it work well with GPUs?

Calling C code can solve most performance and ecosystem issues. Nature natively implements the system ABI for various operating systems and CPU architectures, enabling C code libraries to be called at extremely low cost. In Go, a separate thread + hook is required to call C functions.

I have not yet considered GPU-related features.