I was immediately put off by the Spanish version when I saw it was called "rústico", which does not translate to rust at all, it means rustic. The Spanish word for rust would be "óxido".

"Rustic" is actually a very common term in the Rust community, though it's an obvious joke drawing on 'Pythonic'. But there's nothing inherently wrong with "Rústico" as a name for a programming language.

That's all well and good, except the README clearly states:

> rústico (Spanish for Rust)

which is plain wrong.

full list of signatories: https://treaties.un.org/Pages/ViewDetails.aspx?src=TREATY&mt...

Thanks, this should be added to the OP

What's the difference between this and the first link you shared?

That seemed to an EU thing

But I note the treaties.un.org link is signatories as of late 2024.

Why are they not publishing the current signatories? This is absolutely not something that should be murky.

you can see at the top of the page it says:

  STATUS AS AT : 30-10-2025 09:16:00 EDT

and the date of the signature says 25 Oct 2025.

in the b=2 case, you get:

  1 / 1 = 1 = b - 1
  1 % 1 = 0 = b - 2

they are the other way around, see for example the b=3 case:

  21 (base 3) = 7
  12 (base 3) = 5
  7 / 5 = 1 = b - 2
  7 % 5 = 2 = b - 1

In the b=2 case, 1/1 = 1 = (b-2) + (b-1)/denom(b) = (b-2) + (b-1)/1 = 2b - 3 = (b-1)*b^1 -1 (b-1)

In base 2 (and only base 2), denom(b) >= b-1, so the "fractional part" (b-1)/denom(b) carries into the 1's (units) place, which then carries into the 2's (b's) place, flipping both bits.

Maybe it should be called "lest"? As in a less/most replacement written in rust. Although it does divert from the theme of more/less/most.

> I wonder if an LLM would be up to the job of writing the assembly code from this?

I could see a compiler doing that.

I'm quite aware of the existence of compilers, having worked on bootstrapping a production LISP compiler in the past. My point being that this would be an interesting experiment to do this "naïvely", given how close C is to (for example) PDP-11 assembly code.

presumably the derivation would involve a cryptographically secure, non-reversible function so as to not compromise the secret should one of them be leaked.

It's actually seconds since epoch, not milliseconds. Here's a small program to verify it:

  date -u --date='2038-01-19T03:14:08' +%s | perl -ne 'printf "%#x\n", $_'

It is also mentioned in perldoc Time::Piece [1], as a warning for people whose build of perl uses 32-bit integers for time.

[1]: https://perldoc.perl.org/Time::Piece#Use-of-epoch-seconds

something like this would do it:

  package main
  
  import (
    "sync"
    "time"
  )
  
  type WaitGroup struct {
    sync.WaitGroup
  }
  
  func (wg *WaitGroup) Go(fn func()) {
    wg.Add(1)
    go func() {
      defer wg.Done()
      fn()
    }()
  }
  
  func main() {
    var wg WaitGroup
    wg.Go(func() { time.Sleep(1 * time.Second) })
    wg.Wait()
  }

This is really amazing, thank you so much!

It's called struct embedding, there an article about it in Go by Example if you're interested: https://gobyexample.com/struct-embedding

Thank you @listeria, today I learned about struct embedding lol!

I rediscover this about once a year and am always so happy when I do.

They link to an old article [1] that was featured in HN [2] somewhat recently, in which there's a workaround for older standards with regards to typeof.

[1]: https://danielchasehooper.com/posts/typechecked-generic-c-da...

[2]: https://news.ycombinator.com/item?id=44425461

They mention using this as the backing array for a power-of-two-sized hash table, but I don't think it would be very useful considering that the hash table won't provide stable pointers, given that you would need to rehash every element as the table grows. Even if you just wanted to reuse the memory, rehashing in-place would be a PITA.

I think they mentioned it's for an arena, where stability is necessary. You might happen to use said arena for a hash table