mrtracy

How big are the commitments here? I’m having trouble finding actual dollar amounts. Does this actually represent an infusion of money into these SMR efforts, or are these “commitments” tied to so many missable targets that it’s actually meaningless?

Oklo in particular seems to be total vaporware, I can’t find a single technical picture anywhere of anything this company’s reactor is seeking to do. They seem to raise money based on a rendering of a ski lodge.

A huge, concrete investment in TerraPower would be more interesting, but as a molten salt SMR which has never been built, this also looks extremely non-committal.

SMRs in general seem like a dead end, we’ve heard about them for decades and they don’t seem to be any closer to making nuclear power buildouts less expensive.

Everything that makes proven nuclear power plant design expensive seems to revolve around the same drivers of expense for all long-term construction: large up front capital requirements, changing regulations, failure to predict setbacks, and pervasive lawsuits. SMRs purport to tackle a couple of these (shorter-term builds, fewer setbacks), at the cost of considerable efficiency, but so far this seems like an inferior alternative to “just get better at building proven nuclear plant designs”.

Many of the levels in that game take place on tiny planetoids with spherical surfaces and central gravity. "Spherical" sells it short, there were some truly wild topologies around which Mario could run and jump.

It's an elegant rendering trick, but if their worlds are represented as a torus, then I expect this would make rotation on a spherical globe view unintuitive.

One example of this: I would expect each location would not have a single antipode (opposite coordinate) but would instead have three. If you were to start at location A, rotate travel 180 degrees along the latitudinal axis to location B, then 180 degrees around the longitudinal axis... on a sphere you would expect to be back at location A, albeit upside down. But on a torus, you are in a completely different location, which is the 'C' antipode. Rotating 180 degrees latitudinally from here will bring you to point D, the last of the antipode set.

Wonderful write-up of attempting to tackle this problem. I believe there must be a significant number of people who have played both Minecraft and Super Mario Galaxy, and had something like this sequence of thoughts - although you have followed it all the way to an actual demonstration, and written up your thoughts along the way so clearly.

The vertical distortion is the biggest issue IMO, there are a few reasonably satisfying ways to approach the horizontal tiling of each “shell”. For example, you can make your world a donut instead of a sphere, and now you have a perfect grid at each level! Of course, this introduces a level of distortion between the interior and exterior, so you also twist the donut once, and now you’ve both solved your distortion problem and invented the stellarator fusion device.

Rust uses the traits “Send” and “Sync” to encode this information, there is a lot of special tooling in the compiler around these.

A type is “Send” if it can be moved from one thread to another, it is “Sync” if it can be simultaneously accessed from multiple threads.

These traits are automatically applied whenever the compiler knows it is safe to do so. In cases where automatic application is not possible, the developer can explicitly declare a type to have these traits, but doing so is unsafe (requires the ‘unsafe’ keyword and everything that entails).

You can read more at rustinomicon, if you are interested: https://doc.rust-lang.org/nomicon/send-and-sync.html

There are tantalizing ways to create fusion which don’t require these precise conditions. For example, a simple farnsworth fusor device gets fusion reactions just by causing atoms to cross paths at super high speed until they collide - they simply don’t collide often enough to release anywhere near a net energy gain.

Inertial confinement fusion, such as the National ignition facility, does generate comparable pressures and temperatures to the core of the sun within the fuel pellet for an extremely small moment during an implosion. This is done by focusing a lot of energy on small target.

Plasma confinement techniques don’t utilize high pressure to create fusion; they rely on extreme temperatures which are significantly hotter than the core of the sun, which can produce fusion events in a plasma which is only pressurized to around 1 atmosphere (they also rely on different fuel types than the sun which fuse much more readily). The key is once again focus, a large amount of energy is put into a small amount of gas. The obvious issue with this is that the extreme temperatures would destroy any physical container rapidly - but given the electromagnetic nature of plasma, it can be contained using a strong magnetic field without reaching the surface of its physical container.

This would work very well for medicine/procedures which are known to work very well, to both doctors and consumers. This includes medicine which is already OTC (pain relievers), but also probably anything they can do at an urgent care: x-rays for broken bones or sprains, throat cultures, antibiotics (drug resistance is complex for this but people generally know they work).

Where costs will inevitably get complicated are:

1. emergency medicine, where the purchaser is in severe pain or possibly unconscious.

2. conditions without cures, or possibly even well-established treatments, and there is thus active experimentation and disagreement

Both of these are unpredictably expensive to an extraordinary degree, and the second category is sometimes rare enough that economies of scale don’t come into play for individual conditions.

I think government coverage of emergency medicine, aka ERs for severe injuries, is relatively uncontroversial due to its nature of treating unconscious patients.

However, that other category is very large in modern medicine. It includes all chronic conditions without cures, for which many options are available and improved techniques are constantly sought - and it includes complicated conditions where treatment has risks involved, which is basically a huge range of surgeries.

The problem in these areas is that the consumer does not have adequate understanding of the efficacy of what they’re buying, yet they’re driven to buy it strongly by pain and suffering. They are likely to want to do whatever a doctor or hospital tells them to do.

What is needed here is a consumer advocate with medical knowledge to keep prices consistent. In the US, this is provided by a mixture of regulation, medical malpractice lawsuits, and insurance companies.

Insurance companies are now failing in that role, but removing them entirely without any sort of replacement is going to leave the courts as the major vehicle to manage the costs - that isn’t a system renowned for efficiency.

I work with this algorithm quite a bit in a personal project. (I've changed from calling it WFC to Model Synthesis; Paul Merrell earned the naming rights, unless we discover an even earlier description.)

I mentally divide it into two important components:

1. Cross-correlation (the 'wave function')

2. Label selection (choosing where the 'collapse' occurs)

The "cross-correlation" is exactly what it sounds like - given an incomplete model and a set of example patterns, this data structure represents the cross-correlation of every place that any of the patterns would individually fit in the incomplete model. I think this is the most useful structure in the algorithm, and is a form of iterative 'feature detection' over the incomplete model.

I think there are many interesting things which can be done with this which aren't in the basic algorithm, such as:

- Having larger indivisible 'patterns' and collapsing such patterns all at once. Although example patterns are always broken down into discrete cells, larger patterns can exist where each cell gets a unique label and very limited transition set. The cross-correlation will detect where they can be placed, and if one is chosen the entire pattern could be chosen at once.

- Partial seeding of labels, e.g. selecting portions of the incomplete model and artificially limiting the available labels in that area, without collapsing it.

- Addition of information to labels which aren't easily expressed in an example pattern, such as rudimentary counting of distances.

The 'label selection' portion (in WFC terms, this is the algorithm used to choose which space to 'collapse') is where all of the random generation comes into play. If using Model Synthesis for full world generation, this is what should be focused on for generating more interesting types of environments.

However, given the common label selection algorithms I've seen and used, I think that Model Synthesis excels mostly at adding small-scale, largely self-similar patterns onto constraints provided by a larger structure. I think that other proc-gen methods better lend themselves to generating large-scale structures. A combination of the two - generating a large-scale structure to serve as a constraint, and allowing model synthesis to fill in interesting detail - seems like a good path to explore.

It appears that Show HN has special algorithmic handling, which is why you would expect stricter rules.

This release has Observer and Hooks which in my opinion really elevate the ability to express complex, reusable structures in the ECS.

For example, one of the well-known challenges in the paradigm is working with hierarchies or graphs - observers are a powerful tool for communicating between specific entities, and should make this a lot easier to express.

Hooks offer the ability to enforce cross-component consistency in a way that wasn’t previously available.

I think there’s some possibly good investment advice to extract here, if you’re able and willing to invest in fusion startups: based on the need to compete with renewables alone, commercial success implies that highly complex reactors simply may not have a market based on construction cost, even if they do generate power.

Of the fusion startups mentioned in the article, I’d say that makes Zap Energy the one worth gambling on (if you’re a gambler that is), as its success apparently depends on exploiting a fluid dynamics effect which was not well known in the past (“shear flow”). If this sufficiently solves the confinement problem, the resulting device looks ludicrously simple in comparison to contemporaries.

Of course it may not work at all, I sure don’t know if it will; but if you had to invest in one of these, that seems like the one where successful power generation actually creates a marketable product.

Peaker plants are considerably less efficient than base load gas energy, because the constantly running plants use a combined cycle. In both types of plants, the fuel is burned in a gas turbine to directly generate power; however, in the combined-cycle plant the waste heat from this is used to generate steam to run steam turbines, capturing additional power; this actually generates over twice as much useable energy per unit of fuel. Peaker plants cannot effectively use this mechanism as it has a much longer start-up time.

Combined cycle is a major reason that gas power plants are so attractive; the inability to use it in Peakers is a reason why they are so unattractive.

The C++ smart pointers dont prevent multiple threads from mutating the pointed-to data at the same time; multiple threads can both access a unique_ptr at the same time and mutate its contents. Rust requires shared pointers (Arc) to also explicitly implement some sort of Mutex-equivalent runtime safety check in order to mutate the data. Rust also has explicit notion of thread ownership, and whether individual types are safe to pass to different threads; if a construct is not thread safe, Rust will prevent you from using it in multiple threads.

As a benefit of the thread-safety notion, Rust can have two reference-counting pointer types: Arc, which uses atomic reference counting and is roughly equivalent to std::shared_ptr, and Rc which does not use atomics. Rc cannot be used across multiple threads at the same time, and the borrow checker will prevent you from doing this.

Rc is appropriate for data structures which internally benefit from multiple pointers (e.g. graphs) but where all of that information is internal to a single data structure - this becomes available without paying the price of atomics.

Nuclear actually is safe by pure incident metrics, even when counting higher casualty estimates for Chernobyl.

The safety, of course, is not intrinsic: nuclear material is obviously very dangerous, especially in a running reactor.

The safety record stems from the considerable regulation around building and operating these reactors, and the fact that the reactor has so little external surface area once running:

* A very small fuel acquisition operation in comparison to fossil fuels.

* Likewise, no externally released pollution outside of accidents, which is rare.

* sites chosen for construction are picked for their stability, and are heavily engineered, meaning you also don’t have the installation worksite deaths which run up numbers for wind and solar.

But again, this is only realized if the operational safety onsite is maintained. That said, it’s not the only dangerous power generation site: dammed hydroelectric can be a considerable danger depending on what is downstream.

In general, I think nuclear would be very popular if natural gas and solar were not available; however, the costs to keep it safe are too high for it to be economical compared to those two sources.

I recently learned that Godot forbids auto in its core C++ codebase, their rationale was based on code review:

> Keep in mind hover documentation often isn't readily available for pull request reviewers. Most of the time, reviewers will use GitHub's online viewer to review pull requests.

`using` directives and typedefs are not forbidden, so this would avoid situations where a type is never explicitly declared.

Having worked in large code bases that used `auto` almost exclusively when possible… I’m not sure I agree. However, I understand.

https://docs.Godotengine.org/en/stable/contributing/developm...

I think that the SQL-on-top, and optimistic model, are definitely things that can have a workflow-dependent performance impact and are relevant.

All databases do suffer under some red line of write contention; but optimistic databases will suffer more, and will start degrading at a lower level of contention. “Avoiding contention” is database optimization table stakes, and you should be structuring every schema you can to do so; but hot keys are almost inevitable when a certain class of real-time product scales, and they will show up in ways you do not expect. When it happens, you’d like your DBMS to give as much runway as possible before you have to make the tough changes to break through.

SQL-on-top becomes an issue for geographic distribution; without “pushing down” predicates, read-modify-write workloads, table joins, etc. on the client can incur significant round-trip time issuing queries. I think the lack of this is always going to present a persistent disadvantage vs selecting a competitor.

And again, given FDBs multiple-full-secondary model, it’s only a problem when working in real time, slower queries can work off a local secondary. But latest-data-latency is relevant for many applications.

They absolutely were, yes. There are very valuable application profiles where FoundationDB's design is excellent, and you can see that from its internal usage at large companies like Apple and Snowflake.

FoundationDB has, in my experience, always been well regarded in DB development circles; I think their test architecture - developed to easily reproduce rare concurrency failures - is its best legacy, as mentioned in a comment above and frequently before.

However, since these topics are always filled with effusive praise in the comments, let me give an example of a distributed scenario where FDB has shortcomings: OLTP SQL.

First, FDB is clearly designed for “read often, update rarely” workloads, in a relative sense. It produces multiple consistent replicas which are consistently queryable at a past time stamp, without a transaction - excellent for that profile. However, its transaction consistency method is both optimistic and centralized, and can lead to difficulty writing during high contention and (brief) system-wide transaction downtime if there is a failover; while it will work, it’s not optimal for “write often, read once” workloads.

Secondly, while it is an ordered key value store - facilitating building SQL on top of it - the popular thought of layering SQL on top of the distributed layer comes with many shortcomings.

My key example of this is schema changes. Optimistic application, and keeping schema information entirely “above” the transaction layer, can make it extremely slow to apply changes to large tables, and possibly require taking them partially offline during the update. There are ways to manage this, but online schema changes will be a competitive advantage for other systems.

Even for read-only queries, you lose opportunities to push many types of predicates down to the storage node, where they can be executed with fewer round trips. Depending on how distributed your system is, this could add up to significant additional latency.

Afaik, all of the spanner-likes of the world push significant schema-specific information into their transaction layers - and utilize pessimistic locking - to facilitate these scenarios with competitive performance.

For reasons like these, I think FDB will find (and has found) the most success in warehousing scenarios, where individual datum are queried often once written, and updates come in at a slower pace.

Co-routines can be a great structured-programming tool for implementing state machines. A good article which explains this idea explicitly: https://eli.thegreenplace.net/2009/08/29/co-routines-as-an-a...

That said, overhead always needs to be considered; the overhead cost of using a CPP co-routine would be considerable for implementing a state machine that transitions rapidly.

Co-routines (when used as an async primitive) are an an alternative to callbacks.

Callbacks exist to avoid the overhead of marshalling async results back to the original calling thread: instead of having the calling thread poll until the child thread(s) pass their results back, the calling function returns after kicking off the children, and one of the children directly resumes the work directly when the results are present. This is a significant performance gain.

However, callbacks have famously poor ergonomics, so many structured alternatives have been created: Promises/Futures, Async/Await, and CPP Coroutines.

As someone who has been maintaining a growing React/Redux app for a while now, this one has kept me up at night.

The main arguments in favor of Vue.js revolve around the idea that it is easier for new developers to understand; that people can pick it up and immediately be productive, with React/Redux being much harder to understand. As someone who wants to onboard new developers onto my project, it makes me wonder if I need to look into a switch, if not for my current project then for the next one.

A lot of the commonly touted differences are either a wash, or are only benefits for very small applications with perhaps a single developer. These would be Templates vs. JSX (This is a wash, they're the same thing, but this maybe even favors JSX for large applications), running Vue.js without a build system (you will want a build system regardless for any production application), "Two-way data binding" (Fools gold, will cause horrors if you ever use watches, you will end up hoisting almost all of your data to Vuex anyway in a production application) and "Single-file components" (Really skeptical that this will make a difference in development vs. any other organizational strategy). I can expand on any of these, but they've already been discussed to death.

+ Where I think Vue.js is actually superior to React:

Vue.js is quite opinionated and clear on where to put both data and computed properties. That's basically it, but it's a huge difference.

React itself is very hand-wavy about where to put data and how to interact with it; it basically leaves the problem for someone else to solve. Even Redux, which is designed specifically to store application data, has a weird interface to connect your data to the React application and has no opinion on where to put computed properties. React-router suffers from this same problem as well; you basically end up looking for blog posts on Medium to figure out how to construct an actual SPA out of these components.

This is a gigantic failing of the React ecosystem, and I think this represents almost 100% of the perception (or perhaps even reality) that developers understand Vue.js better than React.

+ Where I think React/Redux is still better

The React ecosystem takes a lot of inspiration from functional programming; it prefers "immutability" and pure functions whenever possible, and I think this becomes increasingly valuable as your application grows; not just for enormous applications, but even for medium-sized applications.

Even if you're exercising maximum discipline with Vue by hoisting your state to Vuex, you've still got many opportunities to create difficult bugs based on the mutable state. Are you sure you're not referencing mutated state in one your actions? Does one of your components hold onto mutable state in order to do a custom transition or animation? If you're using watchers, you're really risking some dangerous bugs here. Now, I know you probably won't do something silly like this, but as your development team grows and you can't code review everything going in anymore; can you vouch for everyone on your team not to make a subtle mistake with a mutable reference?

React/Redux also enables a few very useful patterns that Vue/Vuex doesn't offer at all. For example, the famous optimistic application is nearly a first-class use case for Redux, but would be quite difficult to implement in Vue. This doesn't matter for small applications; it does matter for large applications. Will it matter for your medium application? The same thing about Isomorphic rendering; Redux was built with this squarely in mind. It won't matter for your small app; are you planning for your app to be small forever?

Finally, because it is all Javascript, I think React/Redux has a much better ecosystem of tooling. That includes both linters and transpilers; for example, writing Vue in typescript isn't especially natural, but it works great with React/Redux. When considering my own purposes, effectiveness with Typescript is one of React/Redux's greatest advantages.

In summary, I would still maintain that React/Redux is better for medium to large applications than Vue, due to its commitment to pure JS and the inspiration it takes from functional programming. However, I definitely see the appeal of Vue.js, and I wish that the React ecosystem would take a note on how to provide clear opinions for developers.

(author)

This is a good insight; Live Lock was one of the things that kept me up at night, although my fellow contributors have allayed my concerns considerably.

In a write-heavy workload where the transactions follow a read-modify-write pattern, it does seem possible that your application could be facing live lock concerns. So, let's look at where those concerns come from in CockroachDB:

1. For write-write conflicts, live-lock concerns comes from the fact that a later transaction can abort your in-progress transaction if it has a priority. On top of this, if your transaction ends up aborting an earlier transaction, the other transaction may retry with a potentially higher priority, and this can result in a "priority war" of sorts.

2. "Read-write" conflicts have a worse problem: if a transaction with a later timestamp reads a key before your transaction writes to it, then your transaction always aborts. In read-modify-write workloads where the read is first, this seems to be the biggest theoretical source of live-lock.

Now, as for dealing with those issues.

+ The "Write-write" issue is the smaller concern here. The ratcheting-up of priorities is probabilistic; currently, after enough retries your transaction will have a high enough priority that it will almost certainly make progress. However, we are not totally content with this: we have an issue for our 1.0 release (https://github.com/cockroachdb/cockroach/issues/5727) to do some serious investigation of this, with some alternatives already suggested. For example, one such alternative is using "lowest original timestamp wins" to settle conflicts instead of a random priority.

+ The read-write concern seems more problematic; our read timestamp cache retains minimal data due to memory concerns, and thus aborts a bit conservatively (i.e. aborts transactions that might have been able to continue). This can be dealt with by modifying your application pattern - in particular, I would suggest using our "SNAPSHOT" isolation level for many workloads. I didn't cover this in the blog post, but in short the SNAPSHOT mode allows RW conflicts to occur without aborting transactions. SNAPSHOT transactions are subject to the "write skew" anomaly, but this anomaly does not occur if the involved transactions write to a common key. This is fortunately the case for many OLTP-type workloads, meaning SNAPSHOT can be used without anomalies; this also moves conflict-detection responsibility entirely to WW conflicts, which abort less conservatively than RW and should ameliorate any live-lock problems.

CockroachDB is optimistically concurrent, so there is not locking. However, your use case is definitely possible.

The transaction would: 1. Read the current document (i'm assuming this needs to be done to compute the translog). 2. Read the latest ID in the translog table 3. Write a new entry to translog with ID+1 4. Write the document.

If any other transaction interleaves with this process (by either reading or writing one of the same keys in a way that would violate isolation), one of the two transactions will be aborted.

(blog author here)

Interestingly, clock drift does not affect the serializability of the transaction history; this system guarantees that the history is serializable, regardless of clock drift.

However, "serializable" only means that the history is equivalent to some serial ordering of transactions - it makes no guarantee that the equivalent serial ordering is consistent with the real-time ordering of the involved transactions. A history with that property (agrees with real-time) is termed "linearizable", and requires additional rules to guarantee in an environment with clock drift.

As mentioned by knz42, there was another Cockroach Labs blog post (written by Spencer Kimball) that addressed this in some detail; that blog post contrasted our strategy for dealing with drift with that of Google's Spanner.

A quick overview of CockroachDB's properties re linearizability: it guarantees that access to any individual key is linearizable, and by composition any two transactions which share a key (that one of the transactions modifies) will be linearizable with respect to each other. However, if two transactions do not have any overlap in modified keys, Cockroach does not (by default) guarantee the resulting commit history is linearizable. CockroachDB's underlying KV layer does have a "linearizable" flag on transactions that can guarantee this, but it requires that transactions be slowed down considerably; Spencer's blog post addresses some other strategies that CockroachDB is considering to address the issue.

Post Author here!

Your understanding of this particular issue is correct: the system described in this post would not be able to provide repeatable reads.

However, as you've alluded to, Cockroach transactions use a form of snapshot isolation (implemented with MVCC) which does provide repeatable reads. And yes, that will be the subject of my next post. :)

Post author here:

In terms of Google products, CockroachDB much more closely resembles a combination Spanner (http://research.google.com/archive/spanner.html) and F1 (http://research.google.com/pubs/pub41344.html). However, while we do share many traits with these systems (a consistently replicated, transactional key/value store with a SQL interface), our internal transactional model is actually quite different.

If you're interested in some of the papers that inspired CockroachDB's transactional model, we have mentioned a number of them in our design doc (https://github.com/cockroachdb/cockroach/blob/master/docs/de...).

As for Percolator, that system is not a general purpose database but an "incremental processor" for large datasets (such as a web crawler). While it does use a snapshot transaction system internally, it appears to use real exclusive access locks, which CockroachDB does not use. Our write intents are not locks, because they do not guarantee exclusive access to a resource (I've expanded on this in another comment on the blog: http://www.cockroachlabs.com/blog/how-cockroachdb-distribute...)

We are not claiming our transaction model to be exceptionally novel, this post is just trying to shed light on a specific property of that model.

Post author here

Sargun is correct, all of our replication is performed by Raft, which exists at a lower level than the content covered in this post. Every command executed against a cockroach key (i.e. "create write intent", "begin this transaction") is persisted to the Raft log before executing; Commands will not proceed if they are not confirmed by Raft. The outcome of all commands is deterministic, so this provides complete replication of all mutations to each key.

If you're interested, there's more information available in our primary design document: (https://github.com/cockroachdb/cockroach/blob/master/docs/de...)

Post author here!

The on disk part of the "switch", our transaction record, can only be accessed internally. There are only a small number of operations to perform on it - create it, read its value, and a small number of deterministic "read-then-write" operations. For example, in the case of an "abandoned" transaction, a later transaction may want to read the abandoned transaction record, see if it is still "pending", and then mark it as "aborted" if it is.

Our runtime orders all such operations on the same record so that they are completely sequential - that is, even for a "read-then-write" operation, it must completely finish before any other operation can occur on that key. This is done using basic runtime synchronization primitives (mutexes, channels, etc).

Hi there, blog author here!

This blog post is not a full description of CockroachDB's transaction strategy. If you're interested, you can find a complete rundown of our strategy here: (https://github.com/cockroachdb/cockroach/blob/master/docs/de...). However, that is a very terse document: this blog post was an attempt to expand on one of the basic ideas behind our design. My goal to clearly explain how we approach atomicity, without broaching the complicated topic of Isolation.

That said, I will attempt to address some of the pain points you raised:

* Cockroach does use a full MVCC system; writes are "append-only" and we keep the full history of values for each key. Keys can be queried at a timestamp, and every write explicitly specifies a timestamp as well (each transaction is assigned a timestamp, all writes will use the same timestamp). With this system, each transaction operates on a snapshot of the database.

* Our strategy for overlapping transactions is straightforward: if two concurrent transactions have a conflict, one of them will be aborted and retried. Write intents (in combination with another component, the "read timestamp cache") are used by conflicting transactions to discover each other. Once discovered, the decision of which in-progress transaction gets aborted is deterministic - each transaction is assigned a random integer "priority", and the transaction with the highest priority always wins the conflict (unless one of the transactions has already committed).

* Every read does need to check the switch if the key being read has a write intent; reads of plain values (with no in-progress transaction) do not need to check a switch.

* Yes, aborted transactions can write intents to the database in our current system. However, the second "write" (consolidation) happens asynchronously, and is not required for the transaction to function correctly. It should only be noticed if the key is accessed again by another transaction before it is consolidated. For committed transactions, I don't believe this is a particularly high price to pay.

A system that doesn't write aborted transactions to disk would be considerably more complex; I think it would involve two commit phases (I. The transaction has been "committed" in memory, and can no longer be aborted by other transactions II. The transaction must successfully commit all changes to disk in an atomic fashion). You likely could get some additional performance (if disk latency is a sufficient bottleneck), but it would be hard won in terms of complexity.