signal-hook VS rust

After few hours of search, I found signal-hook. The issue now is it will not kill process immediately, instead it will wait until the sleep function is done.

If you're interested in the techniques people use here, you might take a look at signalfd - which gives you a way to read signals as-if through a file pipe (so you can use it with things like select/epoll loops) - or signal-hook's implementation of the signal-pipe pattern (which makes use of the fact that write is on the list of async-signal-safe system calls).

Today I learned of Simon Sapin's WTF-8 encoding for UTF-16 text containing invalid codepoints. (Rust source)

I wanted to comment on this a little. The Rust team have gone out of their way to keep Rust's grammar easy to parse! A good example is the turbofish, ::<>, which is used with generics. This PR shows an example of why it's necessary, which lead to the creation of the infamous Bastion of the Turbofish.

The pattern matching is cool! Also, it looks like there's a concat_bytes!() in nightly (issue here) if concatenation is all you need (when it stabilizes or if you're on nightly).

Rust lexer, still no regex.

A huge part of it is working on a compiler that's written in a language that helps avoid mistakes. Even when I was doing C++ regularly I never even tried diving into Clang, because I "knew" I'd be in a mess of complicated manual stuff that I was sure I'd break somehow. But with Rust, I first did a trivial compiler change https://github.com/rust-lang/rust/pull/42275/files#diff-3675ead66a843fefc1a0ac141fac8adeac7899e87979e79d2b4cd2dddd11c2b2, and that was non-terrible enough that I tried a slightly bigger change https://github.com/rust-lang/rust/pull/46264/files#diff-265ef672b5d778c5debaca696bc903a604165df54c44ea4bff07a2369b92e90d, and while I'm far from an expert on the compiler, now I can just go add stuff https://github.com/rust-lang/rust/pull/96376 and it's no big deal.

ICE's are not something C++ exclusive. Plenty of that in rustc. That fact that you hit that while working with C++ is unfortunate, but it could be your experience with Rust as well. The only difference would be Rust's faster cadence and more open community/process so there'd be a chance your issue would be fixed in the next 6-12 weeks.

The partial borrow issue is from a desire to assign names to tuple indices so you can access elements without sensitivity to their order. Without that, any change to the arrangement of components in an ECS archetype would affect downstream code attempting to query-iterate those tuples. Ideally I would use an intermediate struct, but as I discovered over the course of this project, rustc/LLVM aren't great about converting between tuples and structs. The only way to be sure you're not taking a perf hit would be to use a code-generated trait to rename the tuple fields, but you can't do that because traits don't give you direct field access and you can't partial borrow from function access.

There are three. The official one, mrustc (no borrow checker, but can essentially compile the official rustc) and GCC (can't really compile anything substantial yet). Only rustc is production-ready though.