> There is a number of languages that allow manual memory management: ... Nim

Nim not only has support for manual memory management, but there're several gc modes that are not stop-the-world.

Also, since Nim 2, the stdlib now is using ARC by default, which is deterministic and has advantages over conventional garbage collection.

To counter-balance the positive comments - I've found the DLC dissapointing. It replaces fun of trial and error with hours of boring walking in the dark and cheap horror elements. The best part is probably the "surprise" section, but the rest is just meh.

The blog post is missing a link to download page for compiler, which also has some interesting stuff to read:

https://amigasourcepres.gitlab.io/page/benchmark-m2/

Some screen captures of the apps mentioned would be nice too.

ProCalc is pretty sophisticated.

> After 5000 runs, they were all 8.4-9.7%

This sample size is really small. I ran 100 million simulations in Nim[0] (takes around a minute). And distribution converges toward 9.09% on all positions equally:

    Average turns: 65.99609065001634
    Final position distribution:
     4: 9.095%
    11: 9.093%
     7: 9.091%
     3: 9.091%
    10: 9.090%
     9: 9.090%
     1: 9.090%
     8: 9.090%
     2: 9.090%
     6: 9.090%
     5: 9.089%
     0: 0.000%

[0] - https://play.nim-lang.org/#pasty=hwdfbsfh (reduced amount of runs to not abuse playground server resources)

Damn good. Does it matter that you're (presumably) using a psuedo random number? I mean you seem to nail the probabilities regardless.

Perhaps our pseudorandom algorithms are better at flipping a coin (this case) versus having to choose a random value over a range greater than 2 (or "1" if you like).

It should not be a problem, pseudorandom numbers are used in simulations, like monte-carlo, all the time.

Nim uses xoroshiro[0] algorithm for std/random module and it produces good quality statistically random bits until 5TB of output. And lower 4 bits have a little bias, but it should not matter as we only use upper 64 out of available 128 bits.

Also, I just now realise that xoroshiro-128+ is really cheap, so perhaps my batching optimisation was unnecessary here.

[0] - https://en.wikipedia.org/wiki/Xorshift#xoroshiro

Coincidentally, just a few days ago, I tried to run Nim[0] on Windows XP as an experiment.

And to my surprise, the latest 32-bit release of Nim simply works out the box. But Nim compiles to C, so I also needed C compiler. Many versions of mingw I could find online - they all failed to launch.

After some time I managed to find very old Mingw (gcc 4.7.1) that have finally worked [1].

[0] - https://nim-lang.org/

[1] - https://ibb.co/TBdvZPVt

Try MinC, MinC is not Cygwin. Install both the base and the compiler from their page.

https://minc.commandlinerevolution.nl/english/home.html

It's usually code compiled with Mingw that gets AV false-positives in Nim. But, indeed, you can use clang or zigcc compilers instead.

Nim has good support for Clang, so it works by just switching a single flag: `nim c --cc:clang main.nim`

For zigcc - there is a wrapper package you can install with nimble: `nimble install zigcc`

Then you can use it with: `nim c --cc:clang --clang.exe=zigcc --linker.exe=zigcc main.nim`

Of course, you can save the flags in configuration files. You can look at my setup for inspiration [0].

[0] - https://codeberg.org/janAkali/grabnim/src/branch/master/conf...

From what I see, Zen-C aims to be "C with super-powers". It still uses C pointers for arrays and strings. It transpiles to single human-readable C file without symbol mangling. No safety. Not portable (yet?).

Nim is a full, independent modern language that uses C as one of its backends. It has its own runtime, optional GC, Unicode strings, bounds checking, and a huge stdlib. You write high-level Nim code and it spits out optimized C you usually don't touch.

Here’s a little comparison I put together from what I can find in the readme and code:

    Comparison          ZenC           Nim
    
    written in          C              Self-Hosted
    targets             C              C, C++, ObjC, JS, LLVM (via nlvm), Native (in-progress)
    platforms           POSIX          Linux, Windows, MacOS, POSIX, baremetal
    mm strategy         manual/RAII    ARC, ORC(ARC with cycle collector), multiple gc, manual
    generated code      human-readable optimized
    mangling            no             yes
    
    stdlib              bare           extensive/batteries-included
    
    compile-time code   yes            yes
    macros              comptime?      AST manipulation
    
    arrays              C arrays       type and size is retained at all times
    strings             C strings      have capacity and length, support Unicode
    bounds-checking     no             yes (optional)

Seconding this. I was impressed by Void linux stability and speed: xbps (with xtools) might be the fastest and most powerful package manager I've *ever* used.

Sure, Void doesn't have the endless options of Arch+AUR for packages, but it had everything I needed. Even the well-maintained, latest versions of less common software, like Nim compiler.

The author might also missed that Void has a non-free repository, that you have to install for stuff like proprietary drivers, DRM and Steam.

Better way to benchmark zsh startup time is with zprof. Add this to your ~/.zshrc:

    zmodload zsh/zprof
    .. rest of your zsh config ..
    zprof

And then restart terminal.

I was annoyed by this enough that I ended up cloning the OMZ repository locally, and stripping out all the modules I don’t use. And now I just have it as part of my dotfiles[1].

It's just a handful of files and I manually source them in my zshrc[2]:

    source $ZSH/lib/async_prompt.zsh
    source $ZSH/lib/key-bindings.zsh
    source $ZSH/lib/completion.zsh
    source $ZSH/lib/history.zsh
    source $ZSH/lib/git.zsh
    source $ZSH/lib/theme-and-appearance.zsh

It's essentially the same as omz setup I was using before, but loads in just ~25ms (Note: it's on a hard drive, with ddr3 ram and 18ms out of that is spent by compinit)

It also fixed another issue I had with Oh-My-Zsh: whenever they (very rarely) tweak their default config - it breaks my muscle memory.

[1] https://codeberg.org/janAkali/dotfiles/src/branch/main/confi...

[2] https://codeberg.org/janAkali/dotfiles/src/branch/main/zshrc