Peter Me

https://peterme.net - If you've heard about Nim and want to see what someone is doing with it. Along with various other projects and presentations I do.

I've been a Nim respecter for many years, it's slept on in general as a language. The difference here is that Nim compiles to C and you can turn the garbage collector off: Zig compiles C and there's no garbage collector. That means the entire standard library is available when generating object code. It's also trivial to opt-in to the C ABI on a fine-grained basis, by defining a function or struct with the extern keyword. I believe this is still fairly current about the difficulties of building Nim dylibs for C programs: https://peterme.net/dynamic-libraries-in-nim.html I expect Nim will stabilize about where D has: it will have a dialect of the language which, with relatively painless accommodations, is able to produce object code which speaks C ABI. Zig is different. The language is relentlessly focused on providing a better alternative to C while occupying the same niche, and a lot of design time has been spent on making it practical to take an existing C program and start writing the new parts of it in Zig. It's a good language, Nim, and getting better. I'd recommend it for someone who is considering Go, for example.

Lisp macros operate on a representation of the AST. By overhead I mean the nim compiler can generate direct specific instatiations at compile time instead of doing runtime based duck-typing as in lisp. Like, you can have a macro that generates a different expansion based on the type of arguments passed, if you structure the macro that way. The macro can also take entire code blocks as arguments of course, so you can implement general purpose control structures that are first class citizens. Here's an example: https://peterme.net/cross-platform-guis-and-nim-macros.html

Adjacent comment already has a list of concrete libraries/frameworks for large number of areas, so I just want to mention that nim has a very good metaprogramming capabilities, and if the /language/ itself does not feel up to the task you have a lot more freedom when it comes to implementing things. So it really comes down to the community size and amount of money poured in the development, and not fundamental problems with the language design. This is mostly an argument about "technically you can write anything with anything", except in nim's case it is also backed by extremely high flexibility. EDIT: by flexibility I mean - different backends they covet very huge ecosystems (Js and C, and by extension anything they you can interface with using C (like python)) - already mentioned metaprogramming - support for low-level convenience features like custom operators - different memory management options. If you want you can turn off automatic mm completely and write code that deals with pointers and stuff like that directly - more niche things like support for embedding nim interpreter in your programs https://peterme.net/using-nimscript-as-a-configuration-language-embedd…