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

And compilation is fast enough that you can run it as a script with shebang methods.

> 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

I might need to try it out. However, I haven't really found a use case yet where the speed of Python has been a major factor in my day job. It's usually fast enough and is a lot easier to optimize than many languages.

I actually sped up a script the other day that had been written in bash by 200x by moving it over to Python and rewriting the regexes so they could run on whole files all at once instead of line by line. Performance problems are most often from poorly written code in my experience, not a slow language.

> 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

One option that I sometimes use at work (in addition to writing some Python CLIs) that is a pretty nice next step on this spectrum is Bash-with-all-the-fixins'.

I use a Nix-based dependency resolver for shell scripts called resholve¹ to parse scripts so that it can identify all of their dependencies (including Bash itself), then produce a "compiled" script as a Nix build where all of the references to external programs are replaced with pinned Nix store paths.

Then I have a fixed (and recent) version of GNU Bash regardless of platform, so I'm free to use Bash features that are newer or nicer than POSIX sh. My favorite such features are `mapfile` and `lastpipe` for writing in a more functional style, plus of course maps ("associative arrays").

I don't have to worry about portability problems with common utilities, because my scripts will bring along the expected implementations of coreutils, `find`, `grep`, etc. I'm free to use "modern" alternatives to classic utilities (like `rg` instead of GNU grep or `fd` instead of GNU findutils) if they offer better performance or more readable syntax. Polished interactivity is easy to build by just embedding a copy of `fzf`. And while I don't love Bash for working with structured data, it becomes a lot less painful when I can just pull in `jq`.

It's obviously got some disadvantages versus an option like Python, but the amount-of-code to functionality ratio is also much more favorable than Python's.

I typically use this for scripting build and development tasks in projects that already use Nix (via Devenv— I have some unpublished changes to the scripts module that add resholve and ShellCheck integration) to manage their environments, so there's no special packaging/distribution/setup burden.

IME it makes for vastly more readable and maintainable shell scripts than painstakingly limiting oneself to pure POSIX sh, so it can serve quite well as a middle ground option between barebones sh and a "real" programming language as your little script gradually grows in complexity.

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

The deployment story sounds very slick and hard to beat! This is something I might want to try for scripts I want to be easy to distribute on macOS systems that don't have Nix installed.

--

1: https://github.com/abathur/resholve

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

Different strokes for different folks I guess.

Selection sort was the first sorting algorithm that I ever created: Find the smallest element for slot #1. Find the next smallest for slot #2. And so on. I've recreated it from scratch many times. The double for-loop means that it is guaranteed to finish, and it is obviously O(N^2).

I did not learn about Bubble sort until my university class, where I thought, this is a terrible algorithm: It's not completely obvious that it will finish, and it's not obvious what the runtime complexity is. For example, if the inner loop used ">=" instead of ">", it would work for test data sets with unique elements, then hang forever with a real data set that contained duplicates.

> Can you type it from memory, without looking it up?

Well, yeah, but that’s not a very useful heuristic for people who are already aware of the algorithms in question. If you ask people to come up with a way from scratch – probably without explicitly asking, in order to get better success, like by watching how they sort cards – I bet they won’t tend to come up with bubble sort. Maybe that says something about the relative intuitiveness of the approaches? Or not.

I recall "inventing" bubble sort during one of my first CS classes when the question was posed of how to sort a list. So, not that outlandish.

Agree. I remember the names of many of these algorithms, but not the logic.

Let's see.

  for i in 1 .. list.len - 1:
    j = i - 1
    while j >= 0 and list[j] > list[j + 1]:
      swap(list[j], list[j + 1])
      j = j - 1

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*

The reason you rarely hear that mentioned is because basically every programming language is hard to work with from other languages. The usual solution is to "just" expose a C API/ABI.

Of course, C API/ABIs aren't able to make full use of Rust features, but again, that also applies to basically every other language.

Perhaps we can finally stop defining abis in terms of c structs!

If only Rust had a spec to do that with

I don't think they should be defined in terms of any programming language. They should be defined in terms of the architecture - bits, bytes, words and instructions, along with semantics of use. Like we do with networking protocols and file formats.

It's being worked on! https://github.com/rust-lang/rfcs/pull/3470

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

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