[neonsunset]

Could you try a few sample scenarios for a CLI tool written in C# with the following publish options?

JIT:

    dotnet publish -c release -o publish -p:PublishSingleFile=true -p:PublishTrimmed=true

AOT:

    dotnet publish -c release -o publish -p:PublishAot=true

Either one has really good startup time (below ~100ms and 20-30ms respectively depending on what you do), compact binary size and require no external dependencies. Just like in Go except without all shortcomings of Go :)

p.s.: AOT on macOS requires .NET 8 preview (will be released in November)

[raincole]

Interesting, I remembered I've tried something similar to your JIT example but maybe my memory is playing tricks on me. I'll try these again later

[cb321]

20 milliseconds? On my 7 year old Linux box, this little Nim program https://github.com/c-blake/bu/blob/main/wsz.nim runs to completion in 109.62 +- 0.17 microseconds when fully statically linked with musl libc on Linux. That's with a stripped environment (with `env -i`). It takes more like 118.1 +- 1.1 microseconds with my usual 54 environment variables. The program only does about 17 system calls total, though.

Additionally, https://github.com/c-blake/cligen makes decent CLI tools a real breeze. If you like some of Go's qualities but the language seems too limited, you might like Nim: https://nim-lang.org. I generally find getting good performance much less of a challenge with Nim, but Nim is undeniably less well known with a smaller ecosystem and less corporate backing.

EDIT: I make only observations here, not demands. Another observation on the same machine is `python-3.11.5 </dev/null` with an empty environment taking 7.85 +- 0.02 ms.

[neonsunset]

20ms as measured with `time` on Fish shell on macOS. Let's be real, comparing versus Nim here is the same as comparing with C - both are a much lower level languages and don't do as much work on startup (threadpool, GC, etc.) and, for the reference, 60fps is 16.6ms per frame. The difference is unlikely to be noticeable. And this isn't measuring program execution time but back to back console receiving a command to launch a binary, OS doing so, binary starting, doing useful work (displaying hint that the command was not in the correct format) and only then exiting.

[cb321]

I agree this particular C# being >180x slower may not matter much for one-off commands keyed-in by and watched by humans, but that may not be all that matters. E.g., some people might `find . -print | xargs -n1 cmd`. Almost everything almost always "all depends". (On a whole lot. E.g., only @raincole can elaborate on his use cases and what might be missing from the Nim ecosystem.)

EDIT: Also, it's misleading to bundle Nim with C and C's many & storied footguns. While "low-level" is somewhat subjective and you can opt-in to go as low as C (if you so desire), most Nim code is as high-level as Python or C# with various choices in automatic memory management, and the language has very high-level capabilities. E.g., Nim has user-defined operators like Julia. Want to add `=~` or `~` for regex pattern matching? No problemo. In that aspect, Nim is arguably higher-level than C#.