cross-posted from: https://lemmy.ml/post/51402479

I guess Goish might be hated by many Rust fans and Go fans. Anyway, below is the example taken from its website.

use goish::{go, KB};
use goish::sync::WaitGroup;

#[goish::main]
fn main() {
    let wg = &WaitGroup::new();
    wg.Add(1_000_000);

    for i in 0..1_000_000 {
        // Explicit 2 KiB stack, sub-page allocated from the chunked
        // stackpool - the opt-in for extreme spawn density. Everyday
        // code just writes go!(move || ...) and never sizes a stack.
        go!(stack(2 * KB), move || {
            do_work(i);
            wg.Done();
        });
    }

    wg.Wait();
}

I guess Goish might be hated by many Rust fans and Go fans. Anyway, below is the example taken from its website.

use goish::{go, KB};
use goish::sync::WaitGroup;

#[goish::main]
fn main() {
    let wg = &WaitGroup::new();
    wg.Add(1_000_000);

    for i in 0..1_000_000 {
        // Explicit 2 KiB stack, sub-page allocated from the chunked
        // stackpool - the opt-in for extreme spawn density. Everyday
        // code just writes go!(move || ...) and never sizes a stack.
        go!(stack(2 * KB), move || {
            do_work(i);
            wg.Done();
        });
    }

    wg.Wait();
}

The default approach involves using TestClient. However, I found that mocking the database, background tasks, etc., is overkill. Do you have any suggestions?

The Integrity Data Platform (IDP) team decided to rewrite one of our heavy Queries Per Second (QPS) Golang microservices in Rust. It resulted in 70% infrastructure savings at a similar performance, but was not without its pitfalls.

I tested Debian 13 RC1 by installing the Nvidia proprietary driver using:

apt install nvidia-driver

The error from systemctl status dkms is as follows:

× dkms.service - Builds and install new kernel modules through DKMS
     Loaded: loaded (/usr/lib/systemd/system/dkms.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Sun 2025-05-18 07:37:53 +07; 1min 22s ago
 Invocation: da858b6286f04dd6965e54bc964fc78f
       Docs: man:dkms(8)
    Process: 855 ExecStart=/usr/sbin/dkms autoinstall --verbose --kernelver 6.12.27-amd64 (code=exited, status=21)
   Main PID: 855 (code=exited, status=21)
   Mem peak: 6.3M
        CPU: 204ms

May 18 07:37:53 vlegion systemd[1]: Starting dkms.service - Builds and install new kernel modules through DKMS...
May 18 07:37:53 vlegion dkms[1069]: Error! Your kernel headers for kernel 6.12.27-amd64 cannot be found at /lib/modules/6.12.27-amd64/build or /lib/modules/6.12.27-amd64/source.
May 18 07:37:53 vlegion dkms[1069]: Please install the linux-headers-6.12.27-amd64 package or use the --kernelsourcedir option to tell DKMS where it's located.
May 18 07:37:53 vlegion systemd[1]: dkms.service: Main process exited, code=exited, status=21/n/a
May 18 07:37:53 vlegion systemd[1]: dkms.service: Failed with result 'exit-code'.
May 18 07:37:53 vlegion systemd[1]: Failed to start dkms.service - Builds and install new kernel modules through DKMS.

Of course, this problem was fixed by installing 'linux-headers-6.12.27-amd64.'

However, I wonder if 'linux-headers-6.12.27-amd64' should be installed automatically. Is this a bug? How can I check if anyone has reported this already?

The advantages of using Common Lisp are numerous:

1. The shape of tensors is not limited to numbers, but can also include symbols and even S-expressions!
2. Automatic Generation of Iterators, ShapeError, etc.
3. Works as a Domain Specific Language for Deep Learning embedded in Common Lisp

I wonder whether Sony has ever contributed anything to FreeBSD codebase or the FreeBSD foundation.

I want to a tool for conveniently switch between Kdenlive versions using Flatpak.

PicoLisp looks very opinionated to me. It is very interesting for me since it doesn't provide too many choices for beginners.