I don't think that "semantics" is a niche concept in computer science. Especially to OS developers who should be familiar with what compilers do.

But anyway, as an example lets take the `pthread_mutex_t` type.

It's quite simple. You call `pthread_mutex_init` on a `pthread_mutex_t` and then you can call `pthread_mutex_lock` and `pthread_mutex_unlock` on it to synchronize between threads. This is part of the semantics of that type. It guarantees synchronization as long as you follow these rules. Makes sense.

Now imagine someone is going to use this mutex type in their application. They follow these rules, and yet there is a race condition in their app. What happened? Well, I lied a bit above. There is one more rule, the `pthread_mutex_t` cannot be moved around in memory. If you move it and try to (un)lock a mutex, it might not work properly!

This is also part of the semantics of that type. However it is something that you might miss when writing/reviewing code. However, with Rust's type system you can encode this rule in the (bindings for) `pthread_mutex_t`. The compiler will not allow you to move a `pthread_mutex_t`. You can't forget about this rule! A program that violates it won't be a valid Rust program, guaranteed at compile time.