That said, well done for making this.
Lilith: x86-64 OS written in Crystal (github.com/ffwff). [1]. And Crystal has GC.
If people keep doing that, the term will eventually loose meaning. Maybe in 20 years, it will have eroded enough that something like Python will be called a "systems programming language". I mean after all, a printf statement in C also parses the format string at runtime. Who is to say the fact that all of the code is interpreted should thusly exclude something like Python? I'm being sarcastic, if that wasn't obvious.
Nature claims 'concise'ness in it's README's opening paragraph. That is laudable. It's even more laudable if the conciseness would also be reflected in the use of natural language (no pun) that describes it.
Calling it a "systems programming language" while using GC is IMHO eroding the meaning of the term.
Something meaning X and someone including Y and then someone pointing out that X does not include Y has thusly nothing to do with stereotypes here.
See also: "is C a high-level or low-level language?" Just shoot me instead, please.
"Nature is... A general-purpose open-source programming language and compiler designed to provide developers with an elegant and concise development experience, enabling them to build secure and reliable cross-platform software simply and efficiently."
I wouldn't care if my network daemon was written in Python or not, but I would care if the networking stack itself was.
But suppose the very top of stack is high frequency trading system or traffic light controller. Car brakes...
Depending on your stack, determinism may or may not be a key part. And that is only possible if determinism is guaranteed all the way down.
Can you add methods to any type? There is an example of adding a method to a builtin type (string) -- can you add also add a method to a union type?
Any plans to add some sort of enum type? If yes, will it be possible to add methods to enums?
How do you support (or intend to support) Unicode? It says "Strings use ASCII encoding" -- why not UTF8?
The example with a timeout channel does not show how / when the timeout will be triggered. Is this a special kind of channel?
It says "Packages will be synchronized to the $HOME/.nature/package directory" -- will this respect the XDG standard directory structure, which defaults to $HOME/{.cache,.local,.config}?
fn int.to_string() { }
I haven't considered whether union types can add methods, so I tested it, and it seems to be possible, but this may cause some unexpected behavior, so maybe I should disable this possibility for now.
type test_t = int|null
fn test_t.hello() { println('hello world') }
2. Enum support is planned. I plan to use type declarations. Why hasn't enum been added yet? Nature has adopted a conservative syntax design, and I hope to hear more opinions and avoid affecting existing functionality as much as possible when adding syntax features.
type weekly = enum {}
So methods can be added to enums.
fn weekly.found() { }
3. UTF-8 should be solvable via a library. I haven't thought much about UTF-8 yet, but if it can enhance nature's usability, I'll implement it as soon as possible. Usability is a key focus for nature moving forward.
4. Select{} timeout handling does require a special timer channel, which will be addressed in the standard library. Currently, it can only be handled via ch.try_recv() and ch.try_send(), which do not block the channel.
5. Actually, this is the first time I've heard of the XDG standard. I will study and understand the specification.
---
I am not an experienced programming language designer, so thank you for your questions. I will carefully consider them.
If you were to do this again, how would you organize the source code differently?
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”
Definitely a weird thing to advertise.
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.
But I'm confused on why strings use ascii encoding instead of utf-8. What if you need non-ascii characters?
But...
> But at that point, why does it need to be part of the language? Would not a standard library module suffice?
This indicates zig is desired to ship with unicode support—just not part of the core language runtime. Now this I can support—unicode doesn't require core runtime support. Most programs don't have a need for unicode text normalization, for instance, so why would you need this without linking in a standard library? But the idea of not shipping unicode in your standard library rightfully died decades ago.
Notably, this doesn't imply:
* source code being ascii
* string literals being ascii
* unicode string processing not being immediately available in the standard environment
So I'm not sure which behavior is being described here, but I certainly consider utf8 support to be table-stakes for language design in 2025. Without this a language is a toy. I'm not going back to using ICU and will fight anyone who encourages me to.
- 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
And in a very good sense.
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.
Clean source code too, impressive project
I think the goal is great. My dream language is something "in between Go and Rust", Go but with more expressive types, Rust-light, something along those lines. This seems like it is hitting that sweet spot.
Imo Go gets a lot right when it comes to productivity, but the type system always annoys me a bit. I understand the choice for simplicity, but my preference is different.
Rust is quite enjoyable, especially when it comes to the type system. But, kinda the opposite of go, it's a lot, maybe too much for me, and I frequently don't know what I'm doing haha. I also don't really need Rust level performance, most things I do will run totally fine with GC.
So Go with some extra types, same easy concurrency, compilation and portability sounds like a winner to me.
https://en.wikipedia.org/wiki/List_of_filename_extensions_(M...
(int,bool,bool) t = (1, true, false) // v: Define a tuple. Access elements using t[0], t[1], t[2]
string? s = null
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.
The tuple type definition _looks_ like how the tuple will look. The nullable indicator is a symbol with a delightfully appropriate semantic meaning.
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.
Hey, can you comment on how this was achieved?
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.
Go uses a flavour of plan9 asm and then do transformations for each platform to achieve cross compilation.
I wanted to know how this Lang achieved it, is it using qbe or a custom backend?
#local fn test() {
}
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.
