The version banner in the docs prints the Unix epoch

The example version banner says 1970

The install section is short: download the installer from the project's build page, extract it with the correct permissions, move the nature folder into /usr/local, and add /usr/local/nature/bin to the system environment variable. If you install somewhere else you have to set NATURE_ROOT by hand, which is the kind of detail that is easy to miss and produces a command that cannot find its own standard library. Then two commands check the installation, nature -v for the version and nature -h for help. The example output is where the near-reading starts:

> nature -v
nature vx.x.x - release build 1970-01-01

Two placeholders appear in one line. The version is literally vx.x.x, and the build date is 1970-01-01, which is the Unix epoch. Both are clearly illustrative rather than observed output, but a reader skimming for what a real banner looks like will take those two strings as the format, and 1970-01-01 is a value that a naive date parser will happily accept. That is the small thing to remember here: the banner has three fields, a version, a build kind and a build date, and the middle field distinguishes a build kind from a date.

Six targets, and Windows needs nothing else installed

The supported target list is linux_amd64, linux_arm64, linux_riscv64, darwin_amd64, darwin_arm64 and windows_amd64, and the compiler cross-compiles from any supported host. That list is the practical limit of the language today, and the Windows entry has an unusually detailed footnote. Building a Windows x64 console executable from a Linux host is a matter of nature build --target windows_amd64 main.n, which produces main.exe using the project's built-in COFF/PE linker and its bundled Windows sysroot. The README is explicit that Clang, LLD, MSVC, the Windows SDK, MinGW and Zig are not required on the final-user build path. That is a strong claim and a specific one, since producing a PE executable usually means assembling one of those toolchains; having the linker and sysroot bundled is what makes the claim true, at the cost of a larger installer. Deployment is described as simple for the same reason, with bundled target sysroots and statically linked third-party runtimes.

One formatter, no profiles, two front ends

Formatting gets more documentation than most language projects give it, and the design decision is stated up front: Nature ships with one canonical formatter style and is convention-over-configuration, with no style profiles and no user-tunable formatting rules. Two commands expose the same core. nature fmt is the user-facing toolchain command, and nls fmt is the underlying formatter command used by the language server and its wrapper. Editors reach the identical canonical output through the language server's textDocument/formatting request, which means a file formatted by the CLI is byte-identical to one formatted by your editor. The flag surface is where the design shows: printing to stdout is the default and no path means reading stdin, -w or --write rewrites in place, --check and --diff both exit with status 1 when a file would change, -l lists the files that differ, and -e reports all lexer errors instead of stopping at the first.

Invalid syntax is an error, not a best-effort guess

The formatter notes are worth separating from the flag list, because they describe failure behavior. Formatting invalid syntax is not supported, and formatter errors are reported instead of producing best-effort output. That is a real choice: a formatter that reindents a file it cannot parse leaves you with a file that is broken and reformatted, which is worse than a file that is broken and untouched. Combined with the promise that output is intended to be stable and idempotent, the contract is that running the formatter twice changes nothing the second time, which is what makes it safe to run in a pre-commit hook or a CI check. One constraint is stated on the flags: --write cannot be combined with --check or --diff, so the command that rewrites and the command that verifies are mutually exclusive by design rather than by accident.

The project says it has not been tested at scale

The overview section is where an evaluation gets its most useful sentence. Nature has reached an early usable version and its core syntax features are now in place. Key features still to be completed are named: unsafe runtime mode, LLM coding adaptation, C target adaptation and a WASM 3.0 target adaptation. Then the testing position: the project includes a set of test cases and standard libraries to check basic functionality and syntax, and a set of small to medium-sized projects to test overall usability, but it has not yet been tested in large-scale projects. Paired with a tag naming scheme that produces weekly.2026.39 rather than a semantic version, that describes a project shipping continuously and expecting instability. Nothing about that is a criticism of the work; it is a statement of where the risk sits for anyone planning to depend on it.

Concurrency, memory and IO are all in the runtime

The feature list is where the systems-programming claims are made, and the runtime items are the ones worth reading closely. Concurrency primitives are built in as go, future, channel and select. Memory safety comes from a type system resolved statically at compile time, plus exception handling, and the type system supports generics, enum, tagged union, interface, nullable with the ? marker and errable with the ! marker. On top of that sit four runtime claims: a garbage collector with very short stop-the-world pauses, a memory allocator referencing tcmalloc, coroutines with shared stacks capable of millions of switches per second, and IO based on a libuv implementation. The compiler emits machine code for the target directly without relying on LLVM, the C foreign function interface calls standard library functions with zero overhead, and built-in data structures cover vec, string, map, set and tup. Tests are described as first-class, written directly in source files, and package management is centralized under npkg with editor LSP support.

Where Nature is the wrong choice

Four cases. The first is a production service. The project states it has not been tested in large-scale projects and names four features still to be completed, so the honest position is that you are adopting an implementation in progress. The second is a target outside the six listed. FreeBSD and every mobile or embedded platform are absent from the list, so a project targeting one of those needs a different language today. The third is a team that wants a large standard library. What is described is vec, string, map, set and tup, a C FFI, and bundled third-party runtimes, which is a deliberately small surface; a project that needs an HTTP client, a database driver or a serialization library will be reaching through FFI or writing it. The fourth is a language adopter looking for prior art. A compiler written in C that avoids LLVM is unusual enough to be interesting and young enough that migration cost later is the main risk, so the question to ask yourself is not whether the type system is pleasant but whether you can afford to rewrite if a weekly build changes something you depend on.

Editorial conclusion

Nature suits a systems programmer who wants memory safety, built-in concurrency and a compiler with no LLVM dependency, and who is willing to work with an early implementation. It does not suit a production service or a team needing a large body of code already exercised elsewhere. Before adopting, compile the hello world and read the version banner, confirm your target is in the six supported ones, and read the overview section, which states the project has not been tested in large-scale projects.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. nature-lang/nature on GitHub
3. Project website
4. README
5. Releases