Precisely. Any good company won't care what programming language you are specifically proficient in. They care about how proficient you are in learning new things.

I have created a lot of Nim projects and implemented much of its stdlib. My full-time job isn't using Nim, but the experience I gained through my work in Nim has helped my career significantly.

I'm assuming this must be for huge projects?

I just compiled my toy project (detecting anomalous parity in integers) in nim 1.6.6 (4.23s), go 1.17.7 (2.43s to create both aarch64 and x86_64 binaries), zig 0.8.0-dev.1140 (2.04s to create aarch64 and x86_64 binaries) and C via clang 13.1.6 (0.14s).

nim's compilation is 175% of Go, 207% of zig, and 3021% of clang.

I love nim, but I disagree with the "quick compilation" point here. The compilation is horrendously slow. (by default it compiles down to C, then to exe from there).

It’s not as much my code as reading my dependencies, troubleshooting others’ code, and the ecosystem sprawl. I keep up to date and pick and choose what I want.

A lot of these issues just aren’t there in C++, and you probably wouldn’t even try to share a codebase for something with someone who’s not another expert. …and you’re most likely working on something big.

The big thing that’s plagued Python since 3.x is the distribution problem. You can’t just hand someone a script and maybe another one to user-install some requirements. You need to BYO Python, dependencies, etc.

Things like types, library management, etc. are being handled by external tools. If I want to onboard someone to collaborate with me they really have to have my version of Python (so probably pyenv), Pipenv or Poetry, mypy or whatever, pytest or whatever, black, and have the same config for some of them.

The verbosity overhead of Go (or Nim, etc.) is worth the trade off to me for most of my uses of Python. I can just hand someone a binary and the dev just needs the language installed and maybe like goimports.

I’ve never been married to one language. I like to use them for their wheelhouse. I’ll still use Python for 1-offs or some things I can ship in a container, etc. that I’m only working by myself or with experienced Python people on.

A lot of this is that it’s really turning into more of an Analytics language. The output isn’t expected to be shared and everyone around you is a Python dev.

And I’m old. I started when Python was so pretty to my Pascal/C self compared to PERL (shudder). The documentation is still amazing for the language and standard library. (No Google, I want the actual docs.) And you could onboard almost anyone to work on it if they had any programming background because it was such a simple language.

The 2->3 shift was really only bad for complex legacy codebases and when you primarily deal with bytes vs Unicode. The latter is really painful anywhere. It didn’t bother me much. I usually just had to fix a few small things or it gave me a good excuse to kill something that should have been retired anyway.

Finally, an actual book for nim!

I like Nim, but it's not for someone who likes classes.

Nim, Zig, Julia, Rust, so many languages lately ... anyone else with language-choice anxiety?

> Nim goes further there by removing the need for tools like Pandas and numpy. You don't have to write code in "Pandas-style" because native Nim is equally fast and sometimes faster.

Can you clarify this? Is there an equivalent data stack in Nim? Or is it that nim is lighter-weight because, for example, it permits transforming tabular data into language structures natively (i.e., without library support)?