archargelod

For anyone as curious as me, here's short description for each language in the list (excluding most common ones):

    cyclone:       safe C dialect preventing memory errors
    zig:           modern systems language with explicit control over memory
    odin:          another modern systems language
    nim:           Python-like syntax, memory safe, compiles to C/C++/JS
    visual basic:  event-driven language for Windows GUI apps
    actionscript:  language for Adobe Flash applications
    php:           server-side scripting for web development
    typescript:    JavaScript with static types
    elm:           functional language that compiles to JS, no runtime errors
    purescript:    Haskell-like language compiling to JS
    haskell:       purely functional, lazy language with strong types
    agda:          dependently typed functional language for theorem proving
    idris:         dependently typed language for type-driven development
    coq:           proof assistant based on Calculus of Inductive Constructions
    isabelle:      interactive theorem prover
    clean:         purely functional language with uniqueness typing
    unison:        content-addressed functional language with hashes instead of names
    scheme:        minimalist Lisp dialect used in academia
    racket:        a Scheme/Lisp dialect for language-oriented programming
    prolog:        logic programming with backtracking
    ASP:           Answer Set Programming for combinatorial search
    clingo:        ASP solver for logic-based reasoning
    zsh:           extended Bourne shell with advanced scripting
    tcsh:          enhanced C shell with command-line editing
    awk:           pattern-directed text processing language
    sed:           stream editor for text transformation
    hack:          PHP-derived language with gradual typing
    verilog:       hardware description language for digital circuits
    whitespace:    esoteric language using only spaces, tabs, newlines
    intercal:      esoteric language designed to be confusing
    alokscript:    can't find anything =(

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

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

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

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

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

You can replace Python with Nim. It checks literally all your marks (expressive, fast, compiled, strong-typing). It's as concise as Python, and IMO, Nim syntax is even more flexible.

https://nim-lang.org

> Nim "cheats" in a similar way C and C++ submissions do: -fno-signed-zeros -fno-trapping-math

I don't see these flags in Nim compilation config. The only extra option used is "-march=native"[0].

[0] https://github.com/niklas-heer/speed-comparison/blob/9681e8e...

Skyrim mod manager for the Nintendo Switch version of the game.

It’s mainly for personal use because converting, renaming, and packing mods in bulk can be very tedious. Especially if you're always changing your mod list (which is a given).

However, once I make it more user-friendly and add a proper GUI, I’ll likely release it to the public.

If a script is simple - I use posix sh + awk, sed, etc.

But if a script I write needs to use arrays, sets, hashtable or processes many files - I use Nim[0]. It's a compiled systems-programming language that feels like a scripting language:

- Nim is easy to write and reads almost like a pseudocode.

- Nim is very portable language, runs almost anywhere C can run (both compiler and programs).

- `nim r script.nim` to compile and run (cached on subsequent runs) or use a shebang `#!/bin/env -S nim r`

- Nim programs are fast to compile (use debug mode and tcc compiler for almost instant compile times)

- Nim scripts run very fast <10ms (something that was very annoying to me with bash and Python)

- good chances you don't need external dependencies, because stdlib is batteries included and full of goodies.

- if you need external deps - just statically link them and distribute a cross-compiled binary (use zigcc[1] for easy Nim cross-compilation).

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

[1] - https://github.com/enthus1ast/zigcc

Terminating condition in Bubble sort is "did we swap any values during this loop"? Yes -> continue, No -> list is already sorted, exit the loop.

I don't believe that insertion/selection sort is easier to grasp. Can you type it from memory, without looking it up? Here's bubble sort:

    var swapped = true
    while swapped:
      swapped = false
      for i in 0 .. list.len-2:
        if list[i] > list[i+1]:
          swap(list[i], list[i+1])
          swapped = true

One problem of Rust vs C, I rarely see mentioned is that Rust code is hard to work with from other languages. If someone writes a popular C library, you can relatively easily use it in your Java, D, Nim, Rust, Go, Python, Julia, C#, Ruby, ... program.

If someone writes a popular Rust library, it's only going to be useful to Rust projects.

With Rust I don’t even know if it’s possible to make borrow checking work across a language boundary. And Rust doesn't have a stable ABI, so even if you make a DLL, it’ll only work if compiled with the exact same compiler version. *sigh*

This list is missing Nim[1]: nice syntax, extremely fast, memory safe, small binaries

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

HN users are predominantly loyal Apple users and most of them are pro-gatekeeping and for walled garden approach.

So, I am not so sure that they're fully aligned with Clippy movement at whole, which is much more than just "right to repair".

What events did you expect?

It's not a revolution, we can't just go with pichforks to Microsoft offices and demand de-enshittification of Windows.

It's a movement of "we are fed up with this shit".And our only tools are:

making people aware of how awful Windows, Mac and rest of Big Tech world are and to make people switch to Linux, because it's the only platform that is free from this bullshit and gives you some freedom.

> As the number of supporters grow, the less “cool” it becomes

Does it really matter if movement is cool or not? I hate corporate bullshit shoving AI down our throats and enshittifying everything it touches, that's why I changed my profile picture to clippy. I, frankly, don't care about character or what's the meaning behind it. But I want for other people to see how many of us are fed up with shit.

>> I've begun to correlate it with people who are more annoying than average

This I don't understand, because in my experience, people with clippy pfp are usually helpful. I usually see them on the top of youtube or reddit comments, giving good advices and answering questions.

For me, AI slop is anything that was "vibed" with AI. If all it takes is writing a prompt and pressing a button - it's a sloppy, lazy and should not be the end product, period.

But, you can take what AI generates, refine it, change it or use only parts of it, fact check it, etc. etc. Now, it's still AI generated, but not a "slop".

AI can do 90% of your work, but the other 90% is still your job if you want someone else to care about it.

Most content creators have links to support them with donation or patreon.

Once a year choose 3 small youtubers (larger ones are already multi-millioners, they don't need your help) and drop them $5 each.

Now you just did 1000% of what they could get from you watching ads.

Looks nice and pretty light on resources.

But it seems buggy at rendering some unicode characters, I use vertical line[0] for my indentation guides in Neovim, and they look outright hideous in cool-retro-term[1]

[0] https://www.compart.com/en/unicode/U+007C

[1] https://lensdump.com/i/f6qna1

> Never used Nim before so I might be doing something wrong though.

With Nim on weird targets you usually want:

- OS target = any

- Memory Management = ARC

- malloc instead of default Nim allocator

- turn off signal handler (if not POSIX)

- disable threads (most of the time)

Then look at how C is compiled and copy all compiler+linker flags to your Nim configuration. Here's an absolute minimal `config.nims` I used to compile Nim for C64 with LLVM-MOS[1] toolchain:

    import std/strutils
    
    --cc:clang
    --clang.exe:"mos-c64-clang"
    
    --os:any
    --cpu:avr
    --mm:arc
    
    --threads:off
    --define:usemalloc
    --define:noSignalHandler
    
    let args = [
      "-isystem $PWD/../mos-platform/c64/include",
      "-I$PWD/../mos-platform/c64/asminc",
      "-L$PWD/../mos-platform/c64/lib",
      "-mlto-zp=110",
      "-D__C64__",
    
      "-isystem $PWD/../mos-platform/commodore/include",
      "-I$PWD/../mos-platform/commodore/asminc",
      "-L$PWD/../mos-platform/commodore/lib",
      "-D__CBM__",
    
      "-isystem $PWD/../mos-platform/common/include",
      "-I$PWD/../mos-platform/common/asminc",
      "-L$PWD/../mos-platform/common/lib",
      "--target=mos",
      "-flto",
      "-Os",
      ].join(" ")
    
    switch("passC", args)
    switch("passL", args)

Nim side was easy, because I have already compiled Nim to WASM at that point and the flags are similar. Hard part was figuring out the C compiler flags: e.g. cmake structure and why compiler complains about missing symbols, when they're not missing (answer: include/lib order is very important).

[1] https://github.com/llvm-mos/llvm-mos

Languages that compile to C (e.g. Nim) are great on older systems. If a system has a working C compiler (or cross-compiler), there’s a good chance that it’ll just work.

I’ve myself compiled Nim on Windows 7, Windows XP, and Haiku, and have run simple Nim programs on the C64 and GameBoy Advance.