Isn't that more equivalent of "I really want to have a typed and compiled language, but I'd also like to keep the Python like syntax". Nim is an underrated language, it's easy to pick up and plenty fast.
You know: this always tempts me, but I hold back because nim is not memory-safe (or has a clearly delineated memory-safe subset like Rust), and I would rather pick up an actually memory-safe (even if GCed) language even if some perf-cost (like F#, Ocaml, Swift, Vale ..etc).
There is a fairly clear subset of Nim which is memory safe. There are discussions once in a while to reduce that from a small set to one..two keywords, e.g.:
https://forum.nim-lang.org/t/9280#61243
which has links to some others. The resolution is usually: Eh - it's already a very small set.
There also may well be libs (that you feel unable to not rely upon) which use these language constructs, and trust sure is tricky (in any PL ecosystem as well as just in life).
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.
how are u compiling (optimization, custom compilation flags etc.?) In my case https://github.com/mratsim/Arraymancer big project compile under your 4.2s so or you have like 10k+ lines of codes with macros or you just pass some debug flags to compiler :D
nim c -d:release --passC:"-flto" --gc:markAndSweep --out:ap ap.nim
I will add that once it's been run a few times, it does go a bit quicker (down to ~0.7s) but the Go also gets quicker (down to 0.28s for two outputs when files are cached.)
$ nim -v
Nim Compiler Version 1.6.6 [MacOSX: arm64]
Compiled at 2022-05-05
Copyright (c) 2006-2021 by Andreas Rumpf
active boot switches: -d:release -d:nimUseLinenoise
No, it is not - Nim's compiler backend is extremely complex and full of cruft. I've been around Nim for 7+ years now and there's a reason the compiler was hard forked.
Nim's compiler is definitely not speedy, and this is why so much effort has been spent on incremental compilation, which tmk, still isn't working - https://github.com/nim-lang/Nim/issues/19757.
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.
> 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)?
This is an interesting take, I do see the value. If I was trying to prevent this type of aliasing, I'd have the compiler throw an error if there were two aliased variables names (xyz and XYZ for example), rather than merging them automatically.
Since Nim is statically typed you can't simply create a new variable with the same name as an existing one without errors. You can shadow variables in a deeper scope, but then only the latest version is available. Defining a function xyz and then trying to define another function xyZ is indeed an error.
