Rin Arakaki rinarakaki

Hello, Rust community!

My name is Hadrien and I am a software performance engineer in a particle physics lab. My daily job is to figure out ways to make scientific software use hardware more efficiently without sacrificing its correctness, primarily by adapting old-ish codebases to the changes that occured in the software and computing landscape since the days where they were designed:

CPU clock rates and instruction-level parallelism stopped going up, so optimizing code is now more important.
Multi-core CPUs went from an exotic niche to a cheap commodity, so parallelism is not optional anymore.
Core counts grow faster than RAM prices go down, so multi-processing is not enough anymore.
SIMD vectors become wider and wider, so vectorization is not a gimmick anymore.

Traits as type constructors

This is a demonstration that we may view traits as type constructors: that is, functions from Type to Type. This view is motivated from a categorical perspective of type theory, in which the morphisms of the category take the central role. Cf. subobjects, which are represented by morphisms, rather than objects in a different category.

I'm assuming that the category of types, Type, is bicartesian closed. The set of morphisms between any two objects includes the set of functions denoted by Fn, FnMut and FnOnce in Rust.

System Design Cheatsheet

Picking the right architecture = Picking the right battles + Managing trade-offs

Basic Steps

Clarify and agree on the scope of the system

User cases (description of sequences of events that, taken together, lead to a system doing something useful)
- Who is going to use it?
- How are they going to use it?

	// ### [ Lexical part ] ########################################################

	_ascii_letter_upper
	: 'A' - 'Z'
	;

	_ascii_letter_lower
	: 'a' - 'z'
	;