virtualritz

I assumed a basic level of abstract thinking since this is HN.

For the point I illustrated it does not matter. Everything is needed. The record somewhere will not be sufficient to get you your flat back when you return from holidays. Nor will a the police w/o a judge. Or the judge w/o having the the record to look at.

And re. "always a computer": trust me, in Germany where I live, it will not be a computer for years to come. Everything is paper here. :D

Yeah, you do not need an oracle for USDC.

But I don't see USDC being mentioned in my reply or the comment I replied to.

And calling the need for oracles a "hard problem" is a neat euphemism the point of which escapes me. It's not solveable.

As someone else wrote: when something goes sideways with their assets the crypto posse call for law enforcement. Or they bent their own rules (DAO/ETH hard fork, 2016 e.g.).

No, you can set the temp on the one I have. Just let it turned off.

Also the bath is covered with a lid.

Exactly.

It's called the oracle problem. It's the Achilles heel of the whole idea.

And it's unsolvable. As soon as you want to trade some coin for something real, you need an oracle.

Wanna buy a flat in a world where (for argument's sake) even the ownership of that asset is tracked on a blockchain?

Let's say I come home from holidays and someone else lives there.

How do I then prove it's mine? Because it says so in some computer?

Someone has to believe that is true and let me enforce that ownership tie.

Those persons (a judge, the police, even if robots by then) are the oracle.

And a more common scenario than theft is btw legal ownership transfer.

What if I die somehow before giving the blockchain keys needed for that to someone?

How will my brother inherit the flat?

Oracle.

That part we can argue about; the upsetting part, if you bothered to actually read the article, is this:

The WaNPRC says the monkey studies have contributed to an understanding how prenatal domoic acid exposure may affect learning and memory: “These findings remain relevant to public health.”

However, there is no clear evidence that the experiments led to changes in public health recommendations.

TL;DR: whatever your agent told you it wrote and you then "confirmed" experimentally: there is a disconnect with reality ... somewhere.

I wasted more time on this, literally and figuratively.

InlinkeKey microbench results below.

Each row is one pass over n keys with three variants interleaved in one process:

  ┌──────────────────────┬────────┬────────┬─────────┐
  │     n = 65536,       │  std   │ bbtree │ bbtree  │
  │    VertexId(u32)     │ BTree- │  Auto  │ Inline- │
  │                      │  Map   │        │   Key   │
  ├──────────────────────┼────────┼────────┼─────────┤
  │ insert               │ 18.3ms │ 12.3ms │ 20.8ms  │
  ├──────────────────────┼────────┼────────┼─────────┤
  │ get                  │ 14.0ms │  9.2ms │ 16.6ms  │
  ├──────────────────────┼────────┼────────┼─────────┤
  │ iterate              │ 0.74ms │ 0.05ms │ 0.10 ms │
  ├──────────────────────┼────────┼────────┼─────────┤
  │ entry().or_default() │ 52ms   │ 47ms   │ 54 ms   │
  │ .push                │        │        │         │
  └──────────────────────┴────────┴────────┴─────────┘

The same pattern shows at 4k and 1M entries and for the (u32,u32) pair and a (u8,usize) tuple my crate uses. Adding InlineKey makes the narrow keys slower than bbtree without inline keys.

It only beats the trait-less version on the 24-byte edge key. But there it still trails std!

Your post's proven (?) u64 impl is possibly the ceiling for this mechanism on my CPU (Rhyzen 6800H, 8 cores/16 threads). It is at parity with std at 4k to 65k on this CPU and about 10 percent ahead at 1M.

Iteration is where bbtree genuinely wins, 5-15x, but my kernel's time is not in iteration. And I guess that is true for most applications.

You eventually need to add and/or get/read data.

Your mileage may vary.

I tested this on a 3D boolean mesh kernel I am working on (this is swapping out std::BTreeMap, no other code changes):

  ┌────────────────────────────────────┬──────────────────────┐
  │       bench 96..1536 faces         │        change        │
  ├────────────────────────────────────┼──────────────────────┤
  │ union/difference,                  │ +11% to +21% slower  │
  ├────────────────────────────────────┼──────────────────────┤
  │ intersection stage,                │ +16% to +34% slower  │
  └────────────────────────────────────┴──────────────────────┘

Then I thought, maybe this shines when you use big maps. I.e. more dense/complext meshes.

So I used one of my test fixtures, a Nefretiti bust scan with a million vertex IDs:

  ┌──────────────────────────────────────┬───────┬────────┐
  │     cage op (seconds, best of 3)     │  std  │ bbtree │
  ├──────────────────────────────────────┼───────┼────────┤
  │ difference                           │ 84.2  │ 83.0   │
  ├──────────────────────────────────────┼───────┼────────┤
  │ union                                │ 83.2  │ 85.6   │
  ├──────────────────────────────────────┼───────┼────────┤
  │ intersection                         │ 61.3  │ 67.1   │
  ├──────────────────────────────────────┼───────┼────────┤
  │ limit-surface difference (best of 2) │ 123.9 │ 147.2  │
  └──────────────────────────────────────┴───────┴────────┘

I.e. a lot of the claims the post makes probably only hold under a specific and possibly narrow set of use cases the author tested agains.

std::BTreeMap must hold ideally hold up well under any use case for such a map. That always means compromises must be made.

Surprise!!!

That reminds me, my hometown, the city of Hamburg, bought back the public utilities it had privatized in the 90's, following a public referendum, in 2014.

I recall that one reason was prices for electricity and gas going up after the privatization.

Go figure.

Companies that violate GPL & Co don't have to be sued any more.

Someone can reverse engineer the binary, soon for pennies, and publish the source.

The setup misses everything that you could do to let me experience his work in a setting reflecting his time.

An Italian Renaissance palazzo, the house of a nobleman of that time, maybe Leonardo's re-imagined studio etc.

Instead I see a museum that one of my architect friends might get excited (or offended) about but which completely removes all context from the works that the format you choose would otherwise naturally enable.

On that note: getting the colors of the paintings right is also tricky.

When you source these paintings you need to feed their color to a linearization process (as they likely will be in some non-linear color space like sRGB) before applying any scene lighting. And then finally do the display transform. Otherwise horrible things will happen (do happen in your current setup) to the colors and Leonardo will turn once in his grave every time someone opens the website. ;)

That is because rustc really maxes out the cores.

Ask your agent to build a simple bash/zsh/whatever cargo wrapper that maintains a machine build lock.

It should exclude cargo check, tree etc. ofc.

CPU contention from parallel cargo runs absolutely kills (build) performance.

Also my setup has instructions that agents keep working if they have open items while the lock is taken; i.e. launch a subagent or a shell with a watcher to run the build and don't block on it.

This makes all the difference when you have multiple agents on multiple workstreams on the same machine and they target Rust.

The agents are only blocked by this when the features they implement are extremely simple.

The average feature I spec and have an agent implement takes an hour or two (Either Opus 5.5 or DeepSeek 4.1 Flash, both at high and using subagents).

In-between the agents do not build that often because that is instructed in my setup.

They build maybe every 20mins when the target is Rust.

Ofc the models do not work like this by default. In fact they want to build all the time.

But as always, you need to tune the harness/setup for what you're using.

IMHO: if you use these models with Rust w/o those constraints/instructions "you're holding it wrong".

Compile times are really only an issue of you need to iterate extremely fast.

One of my spare time projects is a "prompted" 3D modeling app that is now (incl sub-crates I maintain) about 500k lines of Rust.

The link stage is the longest. An incremental build (w. sccache+mold) where I changed a few source files is done and runs after maybe 20s max on my 2022 Rhyzen 6800H-powered laptop.

I think this is acceptable when working on that kind of project.

For games where this matters I usually prototype in some other language first, TS, Python, Lua, whatever then translate to Rust when game mechanics and magic numbers are settled.

Or you simply put those into a config file that gets watched by the game.

At work we have an image manipulation crate that takes like 30mins to 'dev' and about an hour to 'release' build.

The WASM version takes even longer, about 2h, and needs like 55GB RAM during build.

But that crate has only to be built once a month.

And if it mattered we could split it because it's a metacrate made of ~20 sub-crates.

Yeah, it would be nice if Rust were even faster (I remember compile times almost a decade ago, when I started using it)!

But I think for the typical use cases where you would (should!) reach for it, it's quite ok already.

And if not you can work around it quite painlessly.