Yep x402 is for any blockchain rather than just Stripe. I use it: it’s like being able to access a service without having to sign up and get an API key.
How do you use it? I explored building on this as a platform but ditched it because only crypto nerds seem to use it and fiat is used all around anyway.
> MPP provides a specification for agents and services to coordinate payments programmatically, enabling microtransactions, *recurring payments*, and more.
I believe the Shared Payment Token is interchangeable with a payment method id that you attach to a customer object, but that link has very sparse information about how things actually work end to end and what objects mean what.
Are there any nuclear alternatives that don't include strapping low grade bombs to the reactor core (PRW/BWR: water separation -> hydrogen + oxygen -> boom, like happened @ Fukushima) or using coolants that instantly start violently combusting when exposed to air or moisture (sodium)?
I love the promise of nuclear energy, and I understand that every single engineering decision has tradeoffs, but these tradeoffs just seem so bad? Are there really no better options?
There have been some sodium cooled designs that have used a closed cycle gas turbine using nitrogen as the working fluid for the secondary circuit, in order to avoid any issues with sodium-water reactions with a traditional steam Rankine secondary circuit.
There are also fast reactor designs using lead as the coolant rather than sodium. These are interesting, but less mature than sodium cooling. Sodium is better from a cooling and pumping perspective though.
A eutectic is an alloy that has a lower melting point than any of its components.
Lead-bismuth eutectic or LBE is a eutectic alloy of lead (44.5 at%) and bismuth (55.5 at%) used as a coolant in some nuclear reactors, and is a proposed coolant for the lead-cooled fast reactor, part of the Generation IV reactor initiative. It has a melting point of 123.5 °C/254.3 °F (pure lead melts at 327 °C/621 °F, pure bismuth at 271 °C/520 °F) and a boiling point of 1,670 °C/3,038 °F.
Yes, some lead cooled reactor designs have used LBE, others pure lead. Though AFAIU so far the only lead cooled reactors that have actually been built and operated in production have used LBE. There is a pure lead cooled reactor under construction that should be started up in a few years if the current schedule holds.
The improvement is more on the fuel cladding for classic pwr or pebble bed reactors... But even without all this, nuclear is one of the safest sources of power on the planet, because we made it so
Nuclear today isn't that much different from steam engine - the fundamentals make it a technology of the past clearly losing to the today's tech, in this case to the massive solar/wind accompanied by the battery storage.
Nuclear will work in space, as it is the only tech feasible beyond the Mars orbit.
May be, may be the fundamentals will be sufficiently, to make it feasible on Earth, different for thorium MSRs and hopefully for fusion (my favorite is fusion driven thorium reactor - no need for fusion breakeven and relatively safe as turning off the fusion, the source of neutrons, stops thorium fission)
Thorium is inefficient. And its related to steam in that steam converts to heat and power. Differentiates considerably on the front end.
Nuclear solar and wind are all natural complements. This stupid this or that argument only empowers old oil and gas tech looking to hold on to the future.
Steam usage is a wonderful invention. It's certainly not a technology of the past. Nuclear will work anywhere you don't want to have oversized transmission network and where weather conditions aren't stellar, unless ren are combined with another firm source like gas/coal/geothermal/hydro
The AGRs are advanced reactors that use an inert coolant, CO2. In fact they have been designed to cool down quicker than any credible loss of coolant. And have been in service since the 70s, with some slated to go on until 2030.
I mean the LWR fleet has proven to be incredibly safe by any objective measure with deaths per TWhr as good or better than wind/solar. The very incident you mentioned had a direct death count of 0 or 1 depending on who you ask. Industrial shit blows up all the time, you just don't hear about it because it's normal and accepted.
What needs to improve about nuclear is our ability to deliver it on time and on budget. Safety is already more than adequate.
That is never going to happen until we are building more of a consistent design. I think every LWR is use today is a custom bespoke piece of equipment.
Yes, standardizing on a handful of designs will help immensely, as well as building two or more reactors on one site to share the overhead costs between units.
For example, building out more AP-1000s is really a no brainer. The first-of-a-kind is always expensive and the AP-1000 was especially so due to many factors. We bore that cost and now we should reap the benefits of Nth of a kind builds.
The International Atomic Energy Agency (IAEA) maintains a database of advanced reactor designs, ARIS [1]. It lists 119 reactors. A lot of them are small modular reactors, and the IAEA has published a book with details about them [2]. Some of these reactors have applied for NRC approval, and you can find an enormous amount of details at the NRC website [3].
To answer your question: numerous reactor designs are very safe.
Let's start with the most techonogically mature: helium cooled gas reactors. Helium is a noble gas, chemically inert, transparent to neutrons (the only substance in the universe to have zero neutron absorption cross-section), and it has a hard-to-believe high heat capacity by mass. The downside is that helium is somewhat expensive and it can leak. China has been operating 2 such reactors for the last 4 years [4]. In the US, there is a reactor design, Xe-100, that is quite similar to the Chinese design. It is quite difficult to come up with a scenario where something bad can happen with such reactors. The only problem is that they are quite expensive to build and operate, compared to water reactors.
There is one design that is very similar to the design of helium-cooled gas reactors, the only difference is that the coolant is not helium, it is a molten salt. In the US, the company Kairos is pursuing NRC approval for their reactor Hermes. The molten salt has lower heat capacity than helium by mass, but much higher by volume. There is no need for pressurization. The salt used here is a mixture of lithium fluoride and beryllium fluoride (FLiBe). Fluorine is an extraordinarily corrosive substance, but exactly because it is so, the salts that it forms are extremely stable. Still, stable or not, they can't match the inertness of helium, so such molten salt reactors are a bit more challenging when it comes to the contact between the coolant and the reactor vessel. However, they are extremely far from being a "low grade bomb". These reactors are almost as safe as they can be, albeit a bit below the inherent safety of helium cooled reactors.
Hijacob, AxonML author here. Our autograd is ~3K lines of Rust. Here's the actual architecture:
Three core pieces:
1. The GradientFunction trait — every differentiable op implements this:
pub trait GradientFunction: Debug + Send + Sync {
// Given dL/d(output), compute dL/d(each input)
fn apply(&self, grad_output: &Tensor<f32>) -> Vec<Option<Tensor<f32>>>;
// Linked list of parent grad functions (the "tape" edges)
fn next_functions(&self) -> &[Option<GradFn>];
fn name(&self) -> &'static str;
}
GradFn is just an Arc<dyn GradientFunction> wrapper — cheap to clone, identity via Arc pointer address.
2. Forward pass builds the graph implicitly. Every op creates a backward node with saved tensors + links to its
inputs' grad functions:
// Multiplication: d/dx(x*y) = y, d/dy(x*y) = x
pub struct MulBackward {
next_fns: Vec<Option<GradFn>>, // parent grad functions
saved_lhs: Tensor<f32>, // saved for backward
saved_rhs: Tensor<f32>,
}
impl GradientFunction for MulBackward {
fn apply(&self, grad_output: &Tensor<f32>) -> Vec<Option<Tensor<f32>>> {
let grad_lhs = grad_output.mul(&self.saved_rhs).unwrap();
let grad_rhs = grad_output.mul(&self.saved_lhs).unwrap();
vec![Some(grad_lhs), Some(grad_rhs)]
}
fn next_functions(&self) -> &[Option<GradFn>] { &self.next_fns }
}
The Variable wrapper connects it:
pub fn mul_var(&self, other: &Variable) -> Variable {
let result = self.data() * other.data();
let grad_fn = GradFn::new(MulBackward::new(
self.grad_fn.clone(), // link to lhs's grad_fn
other.grad_fn.clone(), // link to rhs's grad_fn
self.data(), other.data(), // save for backward
));
Variable::from_operation(result, grad_fn, true)
}
3. Backward pass = DFS topological sort, then reverse walk. This is the whole engine:
pub fn backward(output: &Variable, grad_output: &Tensor<f32>) {
let grad_fn = output.grad_fn().unwrap();
// Topological sort via post-order DFS
let mut topo_order = Vec::new();
let mut visited = HashSet::new();
build_topo_order(&grad_fn, &mut topo_order, &mut visited);
// Walk in reverse, accumulate gradients
let mut grads: HashMap<GradFnId, Tensor<f32>> = HashMap::new();
grads.insert(grad_fn.id(), grad_output.clone());
for node in topo_order.iter().rev() {
let grad = grads.get(&node.id()).unwrap();
let input_grads = node.apply(&grad); // chain rule
for (i, next_fn) in node.next_functions().iter().enumerate() {
if let Some(next) = next_fn {
if let Some(ig) = &input_grads[i] {
grads.entry(next.id())
.and_modify(|g| *g = g.add(ig).unwrap()) // accumulate
.or_insert(ig.clone());
}
}
}
}
}
Leaf variables use AccumulateGrad — a special GradientFunction that writes the gradient into the Variable's shared
Arc<RwLock<Option<Tensor>>> instead of propagating further. That's how x.grad() works after backward.
Key Rust-specific decisions:
- Thread-local graph (thread_local! + HashMap<NodeId, GraphNode>) — no global lock contention, each thread gets its
own tape
- Arc<dyn GradientFunction> for the linked-list edges — trait objects give polymorphism, Arc gives cheap cloning and
stable identity (pointer address = node ID)
- parking_lot::RwLock over std::sync — faster uncontended reads for the gradient accumulators
- Graph cleared after backward (like PyTorch's retain_graph=False) — we learned this the hard way when GRU training
with 120 timesteps leaked ~53GB via accumulated graph nodes
The "tape" isn't really a flat tape — it's a DAG of GradFn nodes linked via next_functions(). The topological sort
flattens it into an execution order at backward time. This is the same design as PyTorch's C++ autograd engine, just
in Rust with ownership semantics doing a lot of the memory safety work for free.
Sure, but each request has its own context. Shared resources like DB connection pools will be longer lived but by definition they aren’t alllcated by the request thread. So why not simply exempt everything allocated by a request thread from GC, and simply destroy it on request completion?
Generational GC assumes that short lived objects tend to come in groups, which is probably the best you can do in an OO language with shared everything.
His question is still valid for latency. That parallel GC in Java still seems to pause threads from a quick search. https://inside.java/2022/08/01/sip062/
Don't the models typically train on their input too? I.e. submitting the question also carries a risk/chance of it getting picked up?
I guess they get such a large input of queries that they can only realistically check and therefore use a small fraction? Though maybe they've come up with some clever trick to make use of it anyway?
Yeah, probably asking on LMArena makes this an invalid benchmark going forward, especially since I think Google is particular active in testing models on LMArena (as evidenced by the fact that I got their preview for this question).
I'll need to find a new one, or actually put together a set of questions to use instead of just a single benchmark.
If there’s an issue with the core then the salt tank can act as a heat sink in a way a battery can’t?
The boiling / pressure water reactors all have requirements on active cooling being maintained in emergencies - I’m not familiar with this design nor to what extent the salt is intended to fulfill such a function, but it’s plausible that it could buffer things for idk 1h-3d maybe?
The holy grail is the “walk away safe” reactor, I would hope / presume all the novel / modern ones fulfill that?
A lot of employees at successful startups & FAANG make most of their money from the stock, no? And they need to buy houses and send their kids to fancy schools too, no? So sure, we can reduce it to stock holders, but I’d bet dollars to donuts the 90% of employees who aren’t posting on hn are at least passively ok with “improving metrics”, and some ambitious ones are driving the enshittification initiatives hard.
IMO the reason devs started being paid in stock in the first place is VC-style grow at all costs mentality. The fundraising economy didn’t work without fabricating compensation and only paying out on hits.
No other industry operates with such a blurred distinction between employees and owners. Well, save for the gig economy, itself a tumor on American-style big tech.
Personally I'd be much happier with a stable income with not much upward mobility but also not much risk of falling downwards. Which is what Europe is geared more towards. I don't constantly want to be in a race. Just to live my life.
If they employees want it, fine but don't be surprised if we customers start finding alternatives. And/or pirating their content (e.g. when it comes to streaming services).
But yeah American companies aren't there to support the employees. The only one they answer to are the owners or large shareholders (whichevery applies), and their only goal is to make those richer. Customers and employees alike are nothing but consumables, a raw resource you only treat right if you can't avoid it.
The animation on the page looks an awful lot like autoregressive inference in that virtually all of the tokens are predicted in order? But I guess it doesn't have to do that in the general case?
The example in the linked demo[0] seems less left-to-right.
Anyway, I think we'd expect it to usually be more-or-less left-to-right -- We usually decide what to write or speak left-to-right, too, and we don't seem to suffer much for it.
(Unrelated: it's funny that the example generated code has a variable "my array" with a space in it.)
So, in practice there are some limitations here. Chat interfaces force you to feed the entire context to the model everytime you ping it. Even multi step tool calls have a similar thing going.
So, yeah we may effectively turn all of this effectively into autoregressive models too.
reply