skitter

Although not part of the goal, it also mentions `!Destruct`/"must-move types", aka linear types: Instead of there always being a way to drop values without providing any arguments, if you wanna get rid of a value of a linear type you have to call a function that takes it by value.

By doing the same as with `Sized`: Automatically including the `Forget` bound on generic parameters and letting methods that don't need to be able to forget them opt out. That way existing code continues to compile and existing unsafe code doesn't become unsound.

Why would it be UB? All objects are behind (thin) pointers, which can be overwritten atomically.

I don't understand – what's the point of not collecting mass amounts of personal identity documents and face scans and linking them to online identities?

I do the same in my toy JVM (to implement the reentrant mutex+condition variable that every Java object has), except I've got a rare deadlock somewhere because, as it turns out, writing complicated low level concurrency primitives is kinda hard :p

They're great, compared to cars. But while they have a relatively fast and cheap setup, over the long term light rail and trams are a lot cheaper to run and can coexist with foot & bike traffic easier since the rails make them very predictable.

> for the sole purpose of not having to add them to function signatures all over the place.

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

The author obviously knows that too, otherwise they wouldn't have written about it. All of these issues are just how the language works, and that's the problem.

I do not see evidence that they are against violence against women and girls, only that they are claiming to be.

Yup, that's what I'm doing - storing the two bits needed for an object's monitor in the same word as its compressed class pointer. The pointer doesn't change over the lock's lifetime.

Fun post! An alternative to using futexes to store thread queues in kernel space is to store them yourself. E.g. the parking_lot[0] Rust crate, inspired by WebKit[1], uses only one byte to store the unlocked/locked/locked_contended state, and under contention uses the address of the byte to index into a global open-addressing hash table of thread queues. You look up the object's entry, lock said entry, add the thread to the queue, unlock it, and go to sleep. Because you know that there is at most one entry per thread, you can keep the load factor very low in order to keep the mutex fast and form the thread queue out of a linked list of thread-locals. Leaking the old hash on resizing helps make resizing safe.

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

If you're interested in how the mountains and rivers are generated, it's mostly based on the paper "Large Scale Terrain Generation from Tectonic Uplift and Fluvial Erosion": Each chunk rises (at a noise-based, constant rate) while erosion is applied based on the chunk's slope and the size of its catchment area.

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).

They're rather different: In Rust types only exist at compile time; dyn Any is a normal trait object, so you can only call the trait's methods. With C#'s dynamic, you can call arbitrary methods and access any fields with type checking of those accesses being delayed until runtime, which works because types exist at runtime too.

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

Why limit yourself to one language, when you can have 23 of them in the same Datei?

https://github.com/charyan/unirust

…what? Why bring "AI" into this?

I agree about your greater point of learning about history being important, but very much disagree about your specific gripe. What Ironman says is:

  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.

These are very reasonable!

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.

C# inherited this from Java, which added it because it was designed without generics and therefore decided that the additional expressiveness provided by enforced array covariance was worth the tradeoff of having an unsound type system.

> 1. HTTPS Git repository handling is poor. […] 2. Git fetches seem slower for large changes than using Git fetch directly

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)

If you're interested in conlangs, someone made a language, Grapherit [0], that is "spoken" via the Desmos graphing calculator.

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

A miserable pile of secrets.

This can even turn the following code into a no-op:

    vec_of_u32.into_iter().map(f32::from_bits).collect()

Another solution could be tombstones: When a slot gets cleared and the next slot has an item, insert a placeholder value. During linear probing, treat the placeholder as a normal item (that doesn't match); during insertion & deletion treat the placeholder as an empty slot.

In my very limited experience: In addition to cross-compiling, you want additional features that WGSL doesn't provide if you want to compose shaders, so you'd end up with a tool like naga-oil [1] or wesl anyways.

[1] https://github.com/bevyengine/naga_oil

Finding out a piece of software I'm using is written in Go because crashes with SIGSEGV does not spark joy.

Another syntax oddity (not mentioned here) that breaks most highlighters: In Java, unicode escapes can be anywhere, not just in strings. For example, the following is a valid class:

    class Foo\u007b}

and this assert will not trigger:

    assert
        // String literals can have unicode escapes like \u000A!
        "Hello World".equals("\u00E4");

Optional type annotations are used to improve dynamical languages by adding static typing; we don't see static languages adding untyped places (there's type inference, but there's nothing dynamic about that).

> it prevents me from doing things that I know are correct because it thinks my code will run in a multithreaded environment

Could you elaborate on that? In your case you don't need to worry about Send/Sync, you can use Cell/RefCell, etc. The borrow checker isn't about threading, it's useful in a purely single-threaded context too.

When there's a null pointer dereference, that's a bug in the program; when closing a file fails, that's something external the program must handle.

If another program (or thread) is using the same filesystem, calling std::filesystem functions can be UB.

> Behavior is undefined if calls to functions provided by subclause [filesystems] introduce a file system race.

http://eel.is/c++draft/fs.race.behavior#1.sentence-2

I believe post-monomorphization errors don't show in cargo check, and those are rather rare in Rust.