There's nothing stopping you from using memorable ULA prefixes on your LAN [0] and requiring the use of DHCPv6 for addressing so that each host gets a host part that is easy to remember. Hand-selecting your ULA prefix abandons the collision-resistance that you get from using The Technique to generate one, but if that's something you don't care about, then it's something you don't care about.
Plus, manual address assignment is just as viable in an IPv6 world as it is in IPv4.
[0] fd00::/64 is quite easy to remember, as are fd00::1 and similar.
If I hadn't put my long-running machines' -er- ULA-derived [0] SLAAC addresses into my local DNS ages ago, I'd either do exactly that, or slice off the "redundant" parts of the IPv4 address off, so that I could choose to assign sixteen additional bits of addresses to each host. That is:
- ipv6: prefix:192:168:0:42
would become
- ipv6: prefix::0:42:[0-ffff]
[0] I'm really not sure how to succinctly say "The autonomously-configured addresses on my LAN's ULA prefix".
I understand its all boxes inside boxes inside boxes, but as an outsider it looks confusing mixing data type semantics with memory managment semantics.
It bothers me too, maybe for different reasons, as an experienced rustacean. Code like this is a world of pain (in any language, might I add, even though Rust is the only one that shows you why with the syntax).
Internally shared ownership is a huge anti-pattern and rarely achieves what you’re actually trying to do. Graphs like these are much better represented by splitting the topology from the node data, and using indices or keys to form edges instead of (smart) pointers.
You can use pointers, but then the correct choice is actually raw pointers and `unsafe`, with a safe whole-graph-level API for traversal and access. This is what Rust’s own collection types do internally.
Depending on the shape of the graph (arbitrarily connected, DAG, etc.), it just boils down to whatever convenient way you have of storing lists.
Node data in one list. Indices of node parents in another list of the same length. If you need to find children quickly, you can have another list of lists containing children indices.
The key is to consider the node’s position in the list as its ID, and refer to nodes by that index instead of the pointer.
In most cases, this model is both easier to work with and more performant. For example, you can usually get by with 32-bit indices instead of 64-bit pointers, so things are much more likely to be in cache.
Thanks. So you basically make pointers manually with your own separated stack. Wouldn't make sense to have the ability to just allocate anew stact you dedicate to a graph and let the ownership system deals with it for you? Seems like a missing abstraction.
I recently saw a submission here that does that, by essentially implementing GC in Rust. It is not beginner material though. https://kyju.org/blog/tokioconf-2026/
Edit: also the simplest way how to do cyclic structures is to heap-allocate via Box and leak memory. Box::leak
This is also mentioned in the linked article.
For what it's worth, you can pull the same tricks in any language.
I wouldn't like to work with it, but I wouldn't be too surprised if I encountered a List<Optional<WeakReference<Holder<Node>>>>. A list, containing optionally-present weak references to a holder object (which you might need if you intend to update such an object from a lambda, as those can only take effectively final variables from their parent scope).
I think there's value to the Rust implementation. In many other languages, these wrappers are either non-optional or hidden away with syntax, but they're still present. The Rust approach puts the developer in charge of how data should be exchanged (copied/borrowed/on stack/in heap/etc.). You can write extremely efficient programs that stack very few of those types, with many restrictions on how they ca be passed around to methods, or you can make your life easier at the cost of some performance and clutter.
For clarity, you could do something like this:
type RVec<T> = Vec<Rc<T>>;
type RNode = RefCell<Node>;
struct Node {
value: i32,
children: RVec<RNode>,
parent: Option<Weak<RNode>>
}
That would allow for some much-needed brevity, but it would also fill your code with custom types that others will need to learn about.
Memory _is_ data at the level Rust works. It just has a few abstractions in the stdlib that hide this. And the code you highlighted is taking steps in the "let's add abstraction" direction
I see beginners trip over themselves when they get obsessed with allocation (never mind they're coming from like, Python) but in a language like Rust (or C++) you are writing programs with the intent to control how memory is managed. So it makes a lot of sense to tie memory to the types as a part of their semantics.
It's not without problems, but the idea is less confusing in practice than it seems.
I think it feels a little bit of an Ad for the hardware, especially the way he describes the case, telling you the exact model and how spacious it is. Bit sus but perhaps he is being OVERLY detailed and just likes telling you he has a bunch of CPU's that are well cooled in a case with two big ugly fans on the front (not into that look at all.)
Though I can totally understand, geeky people love details. I have a habit of getting way too detailed in my writings here. So I then spend most of the time editing it down to be as clear and brief as possible. I refuse to use an LLM for my own thoughts.
> The appropriated FY2026 budget has the largest discrepancy from the White House Request since 1987 at nearly 30%.[3] The request, submitted in May 2025, proposed a 24% cut to NASA's overall budget.[4] In January 2026, Congress passed the final budget, rejecting nearly all of the proposed cuts.
From wikipedia. The white house is pushing for major cuts to Nasa
Do the satellites broadcast their own position, or is that all held in a database on your phone? Also why is it so draining on your battery to get GPS location, if it's just solving a simple calculation.
Both: they broadcast not the location but the orbital characteristics (ephemeris), and devices can save the last received value. As the satellites get 'perturbed' in orbit, their orbital data is updated and re-broadcast.
The information necessary for a fix is broadcast. The locally stored database helps improve the time to get a fix. A GPS receiver, going from a cold start, needs to listen for many minutes to acquire and decode enough signals to have the required satellite position and timing information to do the calculation.
Most of the power consumption is for the radio reception that has to detect and decode signals from multiple constantly shifting sources, dealing with their very low signal-to-noise ratios and other challenges like multipath distortion due to atmosphere and surface reflections.
It's pretty remarkable how much miniaturization has improved the efficiency of these radios. E.g. going from the early "portable" GPS units that essentially had a lead-acid car or motorcycle battery to today's wearables that run on a tiny power budget while supporting a wider range of satellite constellations and radio bands.
Yes, satellites broadcast their position and time continuously. There's also the database approach (check A-GPS) where you store the satellite's position and query that but just know that it needs to be updated after a while.
Now about the battery draining - the more satellites your phone GPS captures the higher the precision. You need at least 4 satellites to trilaterate aka get precise lat, long. Listening to the signal from the GPS and then trilaterating is an expensive operation- why? because the satellite signal is very very weak and your phone has to run quite a lot of operations (how far the satellites are, then direction) to get the signal from the noise that's hitting your phone constantly. This is loosely the reason for why it drains the battery (even more so during cold starts).
I started to build a gps tracker for my cat which wouldn't require a monthly subscription- after burning the first micro-controller I gave up and decided to leash train my cat. Now my cat is leash trained.
Just receiving on a radio is often a surprisingly expensive operation, especially for a small battery powered device that is otherwise well optimized, and especially when you need to receive continuously like with GPS.
I remember reading something awhile ago in regards to why people were investing in NFTs when it seemed so clear they were a scam. The gist of it was that it's easy to get into cryptocurrency, but it's hard to get out. KYC, taxes, age requirements, currency fees, etc are enough of a barrier that many people would rather just keep those assets in virtual space. Polymarket is the answer to the question "Well what else am I gonna do with this crypto I own"
That's complete nonsense for the simple reason that it is possible to pay just fine with crypto on various sites, also to buy major gift cards. No KYC applies to these actions. We are not living in 2016.
I don't know how much of an issue KYC is to your average crypto-dabbler.
I found a few K's worth of BTC down the back of the sofa recently, and was astounded by how easy it was to use it like Visa after converting to stablecoin.
I don't think prediction markets are a function of stranded crypto, because for most holders, crypto has never been more fungible.
When I was in college I got lured into one of those pyramid schemes advertised in the middle of the night hoping to make extra money. I wonder how much money I would have lost if I had instant access to betting on a "sure thing" back then.
