Found some interesting progresses on io_uring. The zero-copy network transmission with io_uring for TCP or UDP is ready for Linux networking. I also agree that io_uring and eBPF will lead to the next era of Linux programming in the near future.

• Zero-copy network transmission with io_uring
  • Discussion on Hacker News
• Phoronix: IO_uring Zerocopy Send Is Ready For Linux 5.20 Networking
• Phoronix: Linux 6.6 Lands "Pretty Juicy" IOmap Improvements, Lower Latency With IO_uring
• zero-copy RX for io_uring

io_uring with another hot topic eBPF

• How io_uring and eBPF Will Revolutionize Programming in Linux
  • Discussion on Hacker News
• Cloudflare architecture and how BPF eats the world
  • Discussion on Hacker News
• BPF meets io_uring
• BPF, XDP, Packet Filters and UDP
  • Discussion on Hacker News

Resources on io_uring

• RedHat Developers: Why you should use io_uring for network I/O
• The Cloudflare Blog: Missing Manuals - io_uring worker pool
• Dank Wiki: IO uring
• io_uring is not an event system
  • Discussion on Hacker News
• io_uring is not (only) a generic asynchronous syscall facility
  • Computation happened closer to the hardware - Toward decoupled system architecture
• Ringbahn: a safe, ergonomic API for io-uring in Rust
• A Universal I/O Abstraction for C++
• A Programmer-Friendly I/O Abstraction Over io_uring and kqueue
• Adding io_uring to Java

As I mentioned in my previous post, community is very interested and excited about async fn in traits.

In the end of year 2023, it finally happened: async fn in traits is now stable and released with version 1.75.0.

Refs:

• Some recent and notable changes to Rust

Some "corner" cases in Python pattern matching syntax:

match obj:
    case int(0): ...  # special case for 0
    case int(): ...   # any other int
    case float(): ... # any float
    case _:           # anything else

match obj:
    case int as i: ...   # can this work?
    case int(i): ...     # `i` will be `0` in the later context
    case int() as i: ... # any other example from official doc
    case _:              # anything else

I would prefer case int() as i over case int(i)?

Becase the later one feels like i is still unconverted to int yet?

• PEP 634 – Structural Pattern Matching: Specification # Class Patterns

Earning the privilege to work on unoriginal problems

Qiangning Hong (@hongqn) share a Python type annotation tip on X (Twitter), and raised discussions about covariance, contravariance and invariance in Python

from collections.abc import Sequence

a: list[str] =["a"]

def f1(a: list[int | str]): pass
def f2(a: Sequence[int | str]): pass

f1(a)  # incompatible type assignment
f2(a)  # compatible

So why?

The key point is that list[int | str] is not covariant with list[str], while Sequence[int | str] is covariant with list[str].

The reason of Sequence is immutable and is also covariant, most immutable containers are covariant, so f2 cannot modify the list even if it is passed as a list.

List is mutable, so if the parameter is declared as a list type, list[str] and list[int | str] are two different types. In type system, mutable types usually are invariant (e.g. MutableSequence, list, set in Python).

It would be more clear that we add an function to accept Sequence type, and it will be compatible with variable a:

def f3(a: Sequence[str]): pass

f3(a)  # compatible

Refs:

• Tweets from @hongqn
• Tweets from @frostming90
• Tweets from @laixintao
• Covariance, Contravariance, and Invariance — The Ultimate Python Guide
• PEP 483 – The Theory of Type Hints: Covariance and Contravariance
• Wikipedia - Covariance and contravariance (computer science)

Which style do you prefer to declare a variable in C?

1. int *name
2. int* name

Rasmus Andersson (@rsms) open a thread ¹ in X to discuss the history of the convention of put asterisk symbol (*) (also known as unary operator) as a pointer type attched to the name (style 1) rather than the type (style 2).

Nowadays, after a few years of experience as a programmer, I prefer style 2. It's more practical and easier to read in the functional programming way.

There are also many quite interesting comments and supplementary materials in the thread about deferencing operator ²³⁴, historical choices ⁵ and personal flavor ⁶. Worth to dig in.

Only one critical warning to pick the second style

Avoid declaring more than one variable per statement! -- Phil Eaton (@eatonphil) ⁷

That means DO

int* foo;
int* bar;

and DO NOT

int* foo, bar;

Alexis King ¹ is one of my most advocated programmers in PL community. She is doing great! 🥰

Here is a fun and informative answer ² wrote by Alexis for Why do common Rust packages depend on C code?. So I just post it as a recommendation.

Basically, the TL;DR points are:

• C ABIs
• C is your operating system’s interface
• C ABIs are difficult to separate from the C language
• C ABIs are difficult to separate from C toolchains