rnestler

It has it in the AUR: https://aur.archlinux.org/packages/units

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.

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.

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

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

> The real problem is that you can't use crates to improve incrementalism when you have a type in one logical part of the module hierarchy implement a trait from another logical part. Due to orphan rules and coherence, it is not possible to implement a foreign trait for a foreign type.

Well you can implement a trait for a type from another logical part either in the crate of the trait or the crate of the type.

What is the use-case for implementing a foreign trait for a foreign type if you have both under control?

> I wanted to separate the type, the trait and the implementation of the trait in different crates.

I usually put the traits in a separate crate, but keep concrete types and implementations for them in the same crate.

What is the use-case for splitting a type and it's implementation into separate crates? (except for cases where the trait or the type are out of your control, then one indeed needs to use the new-type escape hatch)

> (Plain Windows took ~26 seconds for some reason?)

Maybe the allocations were the reason?

I use Pelican (https://getpelican.com/) for my blog, which works decently for me. It is a static site generator written in Python.

But you probably won't learn much Python by using it (or Rust when using a generator written in it) since you probably won't need to change anything in it. The only Python code you need to write for Pelican is the configuration, which is just setting a few variables.

The build pipeline was already part of Linux 6.1. I played around with it on ArchLinux with the target to compile an out of tree hello world kernel module in Rust:

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

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

I'll probably make a follow up post with Linux 6.2

Nice to see that my blogposts about building a Linux kernel with Rust support on ArchLinux were useful for at least someone else :)

This post does a lot better job at describing the prerequisites to enable Rust in the Linux kernel, while I just referred to the AUR package I created.

MCUs with just 4MB of RAM may not even have IP based networking.

When comparing Rust and C++ it makes sense to use Clang IMO, since both, the Rust compiler and Clang, are based on LLVM.

But nevertheless: I agree it would have been interesting to test with GCC as well.

There is an issue from 2019 on the pipenv tracker for this issue: https://github.com/pypa/pipenv/issues/3893

According to the last comment there it should be fixed:

> I don't think this should be an issue in the current 2022.4.8 release because of the requirement to use index restricted packages for locking. Please advise if you think this is still a concern and we can revisit it.

But apparently it is still an issue (assuming the author did use a recent enough pipenv version)

From the article:

> Overall this is pipenv working exactly as it should.

I don't agree, IMO pipenv should just install from the source package and ignore the newer wheel, maybe showing a warning about the new wheel.

Edit: Just noticed that the author agrees in the end:

> I suppose the behavior I’d like to see here is that if my Pipfile.lock has hashes in it for a distribution, then even if additional distributions are available, pipenv sync should be allowed to continue to install from the distribution corresponding to the “trusted” hash.

I prefer to use https://python-poetry.org/ instead of pipenv, since it has less issues in my experience. But I wonder how it would behave in this situation.

Not really, read the fine print :)

> When multiple moves have the top score, they are all top moves, even if visual markers (like move arrows) suggest the engine prefers one over the other.

This would be the case for two check mates.

Couldn't they just add paging?