My PC has an Intel Xeon from 2007, a GPU from 2010, and 4GB of RAM. It’s enough for web browsing and can handle 1080p/60fps video just fine.

For gaming, I have a dedicated device - a Nintendo Switch, but I also play indie PC games like Slay the Spire, Forge MTG, some puzzle games e.g. TIS-100.

Linux with i3 is fast and responsive. I write code in the terminal, no fancy debuggers, no million plugins, no Electron mess.

It’s enough for everything I need, and I don’t see a reason to ever upgrade. Unless my hardware starts failing, of course.

I realize this is probably said in jest, but just in case there are readers who don’t take it that way:

* someone has to write language specifying a program, natural language or programming.

* a programming langugage is a handle with specific properties at a specific level of abstraction. Whether it’s a popular handle won’t change that it’s far more than a toy.

It was also a direct reference to this scene from Back to the Future Part II: https://m.youtube.com/watch?v=KMy1zO8m8sM

I agree to an extent that tools are not important.

But, for me, there is a certain threshold that a tool must pass to be useful. A tool that is below this level is only slowing you down or limiting your abilities.

You wouldn't use a knife to tighten screws if you have a perfectly good screwdriver lying around. And there's little to no advantage of buying a new expensive or over-engineered screwdriver.

I believe, plain vi is the lowest I can go for writing code. That doesn't mean that I can't use notepad or nano, but they fall under the level of being useful and only cripple and slow me down.

Ghostty passes this level of usability for me, but personally I'm fine with st - no gpu, no cpu spikes, uses barely any ram and still feels snappier. So, what's the point?

Did they consider using Nim? It has great C++ interop, OO and same ARC memory management as in Swift.

> 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)