What is your use case? Isn’t memory cheap nowadays?

I have no idea about Nim but have you checked Go (Golang)? It does the things that you need: single binary, cross compile, easy to learn (except methods on an object are a bit weird at first).

Next to that it is also stable, not dying soon and lots of dependencies to extend the language.

Anyway, if you like Nim, go for it.

fn divide(a f64, b f64) !f64 {
  if b <= 0 {
    return error("divide by zero")
  }
  return a/b
}

fn main() {
  k := divide(1, 0) or { exit(1) }
  println('k is ${k}')
  // or, you can ignore errors at the risk of a panic with:
  m := divide(1, 2)!
}

res := spawn fn() { print('hey\n') }()
res.wait()
// no sync.Wait{} required
// but also:
rv := spawn fn(k int) int { return k*k }(3)
rv.wait()
println('result: ${rv}')

I don’t have proper experience with it, I just built a small prototype with it back in 2021, to evaluate it for a project. But yeah, apparently these were my notes:

Nim: Significant whitespace [derogatory], no interfaces/traits, imports throw random functions into scope like in Python (plays a big role with supposed object-orientation, as methods don’t get imported along with a type; they’re loosely attached and just imported along), somewhat ugly syntax

Apparently, past-me wasn’t as big on the syntax. 😅

But I can see why, because this is the code I wrote back then, apparently (I wanted to create a OS configuration framework à la Puppet, Ansible etc.):

main.nim:

import strformat
import role, host

let host2 = Role(
  description: "sdadsj",
  code: proc (host: Host) = echo "sakjd"
)

echo host2


type Role2 = ref object of RootObj
  description: string
method deploy(self: Role2) {.base.} = discard


type KWriteConfig5 = ref object of Role2
  cheese: string
method deploy(self: KWriteConfig5) = echo fmt"Deploying: {self.cheese}"


let test = KWriteConfig5(
  description: "Deploy KWriteConfig5.",
  cheese: "cake"
)

test.deploy()


let rolerole = Role2(
  description: "RoleRole",
)

rolerole.deploy()

host.nim:

type Host* = object

role.nim:

import host

type Role* = ref object of RootObj
  description*: string
method deploy(self: Role) {.base.} = discard

Certainly some syntax elements in there where I have not even the faintest guess anymore what they would do…

For comparison: rosettacode.org/wiki/Read_a_file_line_by_line

it feels like Python without any of its drawbacks

Uses whitespace for code blocks though. I figured we’ve moved past that.

I just use Rust for this. You can make the binaries fairly small if you put a bit of effort in. Plus it’s not a niche language, and you get the benefit of a huge community. And your code is pretty much fast by default.

The only real downside is the compilation time, which is a lot better than it used to be but still isn’t great.

I wrote a small program that hits a few NWS endpoints and prints out formatted to the terminal. I wrote it in fish, typescript, rust, and nim. Most of my experience is in typescript, rust, java, and kotlin. Nim was my favorite of the bunch. Some syntax things were not my cup of tea, but when you have programmed in so many languages it starts to not matter and feels more like lipstick.

My biggest con with nim was that most of the nim libraries I came across are unmaintained and incomplete and undocumented. I think the language and toolset is pretty great though.

I like Nim very much. It’s like Python to write in, very expressive and easy to read, but compiled. I think it’s a very good choice for small utilities as well as systems programming.

What I don’t like is some people in the project being dicks to others but I just use the language and try not to care about it.

How is compiling Nim binaries compared to Python? I know on Python, the most common choice is PyInstaller, but that only compiles binaries for the type of system it is executed on.

apt install mingw-w64
nim c -d:mingw myproject.nim

I picked it up because I liked the syntax and systems programming capabilities. At least on the surface, it’s fast and expressive.

My main criticisms of the language: the meta-programming features can quickly draw the programmer into unpleasant complexity, and the official docs don’t make it easy to discover small bits of important info when you don’t already know where to look. (And the latter problem makes the former worse). It’s a work in progress, of course, and I believe these problems could be fixed.

I got productive with Nim in a month or two. I dropped it when I found that the BDFL is both routinely insulting to people, and hasty in closing legitimate bug reports. These are both big red flags in my book. I don’t want to have to interact with him again, and I don’t want any of my work to depend on him.

D >>>>> Nim

Scary movie

I haven’t done enough to consider myself a programmer, but I could’ve written your post. It hits a niche that I have long wanted from programming.

You should check out the Godot 4 bindings if you haven’t already (gdext-nim, see my post on !nim@programming.dev). There’s also one for Raylib (specifically, Naylib).

My biggest functional gripe (that I can say for certain is not just me) was that support for (Bellard’s) TCC was dropped. It was nice for quick prototyping, though Clang is a pretty efficient middleground/default.

Never tried Nim, but I saw this on lobste.rs and thought of you: miguel-martin.com/blog/nim2-review