I thought it was because you couldn't be fully generic over exceptions.

As a result, uncontended locks work the same as described in the blog post above; under contention, performance is similar to a futex too. But now your locks are only one byte in size, regardless of platform – while Windows allows 1-byte futexes, they're always 4 bytes on Linux and iirc Darwin doesn't quite have an equivalent api (but I might be wrong there). You also have more control over parked threads if you want to implement different fairness criteria, reliable timeouts or parking callbacks.

One drawback of this is that you can only easily use this within one process, while at least on Linux futexes can be shared between processes.

I've written a blog post[2] about using futexes to implement monitors (reëntrant mutexes with an associated condvar) in a compact way for my toy Java Virtual Machine, though I've since switched to a parking-lot-like approach.

[0]: https://github.com/amanieu/parking_lot [1]: https://webkit.org/blog/6161/locking-in-webkit [2]: https://specificprotagonist.net/jvm-futex.html

The result is a river network as well as the central height of each chunk; based on this roads, caves and structures are laid out. The actual voxels are only determined when a player loads the area and are (usually) not persisted.

Also, for some technologies not related to worldgen: Rendering is done via wgpu, models are built in MagicaVoxel, and both client and server use an ECS (specs).

Rust's dyn Any corresponds better to C#'s Object; dynamic exists to interface with dynamic languages and is rarely used.

https://github.com/charyan/unirust

  7.2.F. (7F.)  FORMAL PARAMETER CLASSES
  There shall be three classes of formal data parameters:
  
      input parameters, which act as constants that are initialized to the value of corresponding actual parameters at the time of call,
  
      input-output parameters, which enable access and assignment to the corresponding actual parameters, and
  
      output parameters, which act as local variables whose values are transferred to the corresponding actual parameter only at the time of normal exit. In the latter two cases the corresponding actual parameter must be a variable or an assignable component of a composite type.
  
  7I.  RESTRICTIONS TO PREVENT ALIASING
  
  Aliasing (i.e., multiple access paths to the same variable from a given scope) shall not be permitted. In particular, a variable may not be used as two output arguments in the same call to a procedure, and a nonlocal variable that is accessed or assigned within a procedure body may not be used as an output argument to that procedure.

7I is important (in the mutable case), and solving the problem that bought forth this rule is the core idea behind Rust.

7F draws useful semantic distinctions: Output parameters are return values. Input-output parameters are mutable references. Input parameters act as a copy or readonly reference – which are equivalent if you can't mutate or observe mutation through readonly references.

Your complaint is that Rust draws a distinction between whether input parameters are implemented via a copy or a reference, but Rust draws many more distictions here – arbitrarily many so, because it's part of the type system. This makes the system both applicable everywhere instead of only in function parameters and allows expressing more different semantics.

For example I have a hard time seing how one would, while following the Ironman requirements, distinguish parameter whos type is "dynamic array of elements of T" from one of type "dynamic array of elements of type mutable reference to T". Likewise you can define a record that holds a mutable reference and an immutable reference, or define a new reference type (such as a reference counted pointer) without new language support.

I said that passing a copy and a readonly reference are equivalent. However, in Rust there are no readonly references. Rather, there are non-aliasing references, which allow mutation, and aliasing references, which by default don't allow mutation – but types can make use of interior mutability to allow mutation through aliased references according to they rules they need. For example you can access data protected by a mutex if and only if you hold the lock, which means that even if other references to the mutex exist, there are no other references to the inner data.

JJ used to use libgit2 for fetches, but it now can shell out to the git binary instead: https://github.com/jj-vcs/jj/pull/5228 (which will be the default in the future)

[0]: https://m.youtube.com/watch?v=HP3nIDAhwYo