Nim VS zig

FWIW, Nim (the programming language) is certainly interesting and possibly underrated.

https://nim-lang.org/

All these organizations[1] using nim in production must disagree with you then.

[1]: https://github.com/nim-lang/Nim/wiki/Organizations-using-Nim

With function overloading and templates

You just use a `hash` function in your library code and user has to implement a version of it that accepts the Foo type.

To resolve the scope problem, Nim uses templates[1] with `dirty` pragma (makes template unhygienic), but there is also a `mixin`[2] statement for later static binding.

0 - https://github.com/nim-lang/Nim/lib/pure/collections/tables....

1 - https://github.com/nim-lang/Nim/blob/78983f1876726a49c69d656...

2 - https://nim-lang.org/docs/manual.html#generics-mixin-stateme...

Check out Nim[0] - it's strongly typed, with good type inference, clean elegant syntax, memory management is automatic (optional gc, default is ARC + small footprint cycle collector), compiles to small single binaries (Hello World is less than 100 kb), has powerful metaprogramming and lsp support.

Nim compiles to C/C++ and then to native code, so performance is on the same level as Rust/C/C++. You can also compile Nim to js/wasm and run the same code in the web.

[0] - https://nim-lang.org

Programming Language: Nim

Take a look at Nim.

You get C performance, with the readability of Python.

https://nim-lang.org/

It’s not exhaustive/definitive yet (should be for the actual release), but this might be helpful:

https://github.com/nim-lang/Nim/blob/devel/changelog.md

One thing I'm super excited about here is that Zig can now cross-compile CGO to macOS [0], granted you link the appropriate macOS frameworks and SDK [1].

[0]: https://github.com/ziglang/zig/issues/20689, https://github.com/ziglang/zig/issues/21721

[1]: https://github.com/tpoechtrager/osxcross

> Chose boring technology. I genuinely find myself picking libraries that have been around for a while partly because that way it’s much more likely that LLMs will be able to use them.

This is an appeal against innovation.

> I’ll finish this rant with a related observation: I keep seeing people say “if I have to review every line of code an LLM writes, it would have been faster to write it myself!”

> Those people are loudly declaring that they have under-invested in the crucial skills of reading, understanding and reviewing code written by other people. I suggest getting some more practice in. Reviewing code written for you by LLMs is a great way to do that.

As someone who has spent [an incredible amount of time reviewing other people's code](https://github.com/ziglang/zig/pulls?q=is%3Apr+is%3Aclosed), my perspective is that reviewing code is fundamentally slower than writing it oneself. The purpose of reviewing code is mentorship, investing in the community, and building trust, so that those reviewees can become autonomous and eventually help out with reviewing.

You get none of that from reviewing code generated by an LLM.

But the situation for Rust-C++ interop is also worse than for Rust-C interop. Why else would Google spend maybe $1 million on improving it in 2024? https://www.theregister.com/2024/02/05/google_rust_donation/ Many years after Rust got support in Mozilla for usage with Firefox written in C++.

>My sibling is also correct, language decisions were made in order to keep FFI zero overhead.

Yet overhead is only one piece of the puzzle for FFI and interop with C, or for that matter, C++.

How does Rust compare with a language with less advanced and more simple semantics and requirements of invariants, like Zig?

https://ziglang.org/

>Incrementally improve your C/C++/Zig codebase.

Regarding the reproducible bootstrapping problem, what is your project's policy on building from binary sources? For instance, Zig is written in zig and bootstraps from a binary wasm file which is translated to C: https://github.com/ziglang/zig/tree/master/stage1

Golang has an even more complicated bootstrapping procedure requiring to build each successive version of the compiler to get to the most recent version.

I love Zig and I love that it’s getting attention, but can someone convince me of its memory safety? One thing that surprised me is that returning pointers to stack-allocated memory doesn’t cause a compiler error — it just segfaults at runtime. This has been an open issue since 2019 [#2646](https://github.com/ziglang/zig/issues/2646).

That, along with the number of memory-related issues in one of Zig’s most popular project, Bun.js [search: segfault](https://github.com/oven-sh/bun/issues?q=is%3Aissue+segfault), gives me pause.

The duck typing argument is absolutely not based on minimal or missing documentation. There wouldn't be countless issues about it in the Zig repository if it were that simple. See https://github.com/ziglang/zig/issues/17198

I'm simply going to quote one of the comments from the linked GitHub issue:

> generic code is hard. Hard to implement correctly, hard to test, hard to use, hard to reason about. But, for better or worse, Zig has generics. That is something that cannot be ignored. The presence of generic capabilities means that generic code will be written; most of the std relies on generic code.

`appendSliceOptimized` is implemented using knowledge of the underlying writer, the way that say an interface implementation in Go would be able to. It's a big part of the reason that reading a file in Zig line-by-line can be so much slower than in other languages (2)

(1) https://gist.github.com/karlseguin/1d189f683797b0ee00cdb8186...

(2) https://github.com/ziglang/zig/issues/17985