The article shows neatly how Rust is inspired by functional programming languages, but polished the concepts by learning from their mistakes.

In the "Purity and Referential Transparency" section I'd have expected some comparison with `const fn` in Rust. Aren't `const fn` in Rust pure?

I tested it quickly on a 30kLOC project. zmypy seems to be faster than mypy indeed:

Without mypy cache:

  $ rm -rf .mypy_cache
  $ time mypy
  Success: no issues found in 157 source files
  mypy  20.40s user 2.33s system 108% cpu 20.886 total

With mypy cache without any changes:

  $ mypy --version
  mypy 1.16.0 (compiled: yes)
  $ time mypy
  Success: no issues found in 157 source files
  mypy  0.56s user 1.84s system 628% cpu 0.381 total

mypy with a small change in a shared module

  $ time mypy
  Success: no issues found in 157 source files
  mypy tests/  2.32s user 2.06s system 168% cpu 2.601 total

zmypy:

  $ time zmypy
  Found 68 errors in 16 files (checked 157 source files)
  zmypy  0.68s user 0.05s system 99% cpu 0.731 total

Without caching and parallelization (as the 99% CPU usage indicates) it comes in the range of mypy using the cache and multiple cores (628% CPU usage) without any changes in the code.

zmypy seems to find more errors but they mostly boil down to the following errors

* Call to untyped function "__setitem__" in typed context

* ... has incompatible type "MagicMock"; expected ...

Maybe __setitem__ and MagicMock are treated specially in mypy? Also there seem to be differences in handling Protocol and enum comparison.

The MagicMock case is indeed interesting. I am not sure what Mypy does there, I would have to investigate. The other issues are probably bugs and should be reported to https://github.com/zubanls/zubanls/issues if you are interested in fixes.

This article is IMO inaccurate in a few points:

> for the first time, we have a Rust-based driver in the mainline kernel.

https://rust-for-linux.com/amcc-qt2025-phy-driver is in mainline since 6.12 and https://rust-for-linux.com/asix-phy-driver even since 6.8

> empowers Nvidia's next-generation open-source graphics hardware. The driver targets Nvidia's RTX 2000 "Turing" series and newer GPUs.

This sounds like it is already fully working, but as far as I know it's just a stub driver merged so far: https://rust-for-linux.com/nova-gpu-driver, https://www.phoronix.com/news/NOVA-Driver-For-Linux-6.15

This makes the article appear as just click-bait to me.

10 years already, amazing. I still remember playing around with pre 1.0 Rust and having my code break on every other compiler update :)

I maintain an AUR package which builds a Rust enabled kernel: https://aur.archlinux.org/packages/linux-rust

So far I just pinned the rustc version used by requiring rustup as a build dependency. Let's see if this lets me drop it or if it is still easier in the end to build with pinned version.

> In addition, if you add "donate" button you'd see a lot of artists being showered with cash.

There are donation buttons for some artist on Spotify. I guess the artist need to enable it? ("Signum Regis" is an artist that has a Donate button for example)

New features include: Live Parts Information via Partstack and EAGLE Project Import.

The EAGLE project import is quite relevant, now that this product will be discontinued by Autodesk: https://www.autodesk.com/products/fusion-360/blog/future-of-...

This looks really nice and useful! I wonder if I could configure it to open things in vim directly? Because currently it seems to use xdg-open which then opens it in whatever application is configured.

> Can I compile rust-written linux modules with a rust-written rust compiler?

The offficial Rust compiler is written in Rust.

> And where can I download bootstrap static ELF64 binaries of this compiler?

You can get a Rust compiler on https://rustup.rs

Probalby you can get one which is statically compiled for the musl target.

If you want to follow the boostrap procedure see https://rustc-dev-guide.rust-lang.org/building/bootstrapping...

Huh, I am unable to get to a nice HTTPS directory tree with sorted builds (looking for that rustc static elf64 binary).

I finally managed to build an ArchLinux kernel that supports out-of-tree modules written in Rust. If you're interested in the whole journey there are also the following posts:

* https://blog.rnstlr.ch/building-an-out-of-tree-rust-kernel-m...

* https://blog.rnstlr.ch/building-an-out-of-tree-rust-kernel-m...