I have not yet considered GPU-related features.

In concrete implementation, it is usually necessary to convert high-level text languages into an Abstract Syntax Tree (AST), perform necessary detection and optimization based on the AST, and then convert it again into a lower-level Linear Intermediate Representation (LIR). After performing necessary detection and optimization on the LIR, the LIR can be converted into readable assembly instructions required by the target CPU. Further implementing an assembly instruction conversion tool converts the readable assembly instructions into binary encoding that the CPU can recognize.

Next, this set of binary encodings is wrapped into an executable file according to the operating system's requirements, ultimately obtaining a file that can run on the target device. Since a compiler is a text transformation tool, it can run this tool on any device - this is the essence of cross-compilation.

Unfortunately, nature is not SEO-friendly, so the name has received a lot of criticism. Therefore, I am considering changing it to a name that starts with ”na”

The tup is an interesting question. I often think about tup(int, bool, string) vs (int, bool, string). I convince myself that there might be a better choice.

`var t = (1 as i8, true, false)` Use automatic inference to replace active type declarations.

t.0 vs t[0] is equally difficult to choose, but t[0] is the more commonly used syntax. Using t[n] consistently across map/vec/set/tup might be the more correct decision.

In my opinion, the change from `<>` to `[]` is a minor adjustment. `<>` is already widely adopted, and I don't want to break with convention for such a small benefit.

The position of the type is similarly considered. Postfixing the type has some advantages over prefixing it, but those advantages aren't sufficient for me to break with convention.

I tried to draw this logo myself, but my drawing turned out rather ugly. The lines of the Millennium Falcon closely match my imagination of the Natural Selection spacecraft's appearance, so I borrowed its lines.

However, this is not permanent. In fact, the name “Nature” may be modified because it is not SEO-friendly.

#local fn test() {

}

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.

I posted this project on HackNews a few times, but it quickly sank to the bottom. Maybe “no LLVM” might pique some people's interest in the project, so I added it. Actually, I posted this link a few days ago and had already given up on it, but unexpectedly, it suddenly appeared on the HackNews homepage.

I now need some attention, which will give the Nature project more capital.