The more interesting question is why we're not GUI yet. I have Thoughts on this, which I'll try to briefly summarize here.
* It's a genuinely hard problem
The state of GUI on Windows is a total mess, very disappointing considering the relative importance and resources that Microsoft has. SwiftUI was a success (Apple is uniquely good at this stuff), but the transition from Cocoa is still not complete. A large part of the reason why it's so hard is that the requirements for different apps vary widely; I think we are spoiled by the relative cohesion
* The infrastructure is in disrepair
A UI is built on top of lots of infrastructural pieces, obviously including graphics and compositing, but also text, accessibility, input handling, and many other things. When you look at support for those layers across platforms, it's like picking up a rock and seeing the bugs crawl. Take compositing: Windows and Mac have excellent compositors, Android and Linux much less so. But even there the features don't line up, Mac doesn't support incremental present (they don't really need to, considering how beefy their chips are, but it's really important on low end Android).
So a lot of the challenge is working around the brokenness across the various platforms. But, good news, there is really excellent progress on all these fronts. We now have solid text layout in Rust, a clear winner on accessibility, and even poor winit is making slow, steady progress.
I'd also like to say, by contrast the web has really been investing in infrastructure, and hides much of the lower level pain from developers. I think that's a major reason Electron is winning so much.
* The computer science is not quite done
We're still in an exploratory phase to figure out the best patterns for writing Rust UI. At the core of that is reactivity, which is at heart incremental computation. Most systems are converging on a hybrid of something generally React like (coarser grain reactivity) with fine-grained signals. I'd like to think there is a Right Answer here and that it's possible to find it.
This feels to me a bit like async. The foundations for async Rust were laid 10 years ago, but it still doesn't feel fully baked. I've seen some exciting recent work about improving the confusing Pin mechanism with something more principled. We'll get there, but it takes time.
I make three predictions:
* Rust UI will continue to improve, as the infrastructure is built out, we try more things, and projects mature. But not quickly.
* If we thought we had a lot of Rust UI projects before, wait til we see what AI wreaks. I predict we'll see dozens of vibe coded Rust UI toolkits.
* In the longer term, we're going to have Rust UI anyway, as browsers are increasingly going to be rewritten in Rust, and apps will be built on Web technology. And that's not just Electron, the modular browser approach pioneered by Blitz is also promising.
Similar, in that it encodes length in the first byte. The differences are:
* It does not require canonicality, it allows multiple encodings of the same value. To make things even more fun, the QUIC spec requires shortest encoding in some uses but not others.
The issue is not type punning (itself a very common source of UB), but the fact that the `bytes` pointer might not be int-aligned. The spec is clear that the creation (not just the dereferencing) of an unaligned pointer is UB, see 6.3.2.3 paragraph 7 of the C11 (draft) spec.
Of course, this exchange just demonstrates the larger point, that even a world-class expert in low level programming can easily make mistakes in spotting potential UB.
> Of course, this exchange just demonstrates the larger point, that even a world-class expert in low level programming can easily make mistakes in spotting potential UB.
A "world-class expert in low level programming" knows that unaligned memory accesses are no problem anymore on most modern CPUs, and that this particular UB in the C standard is bogus and needs to fixed ;)
C of course is ancient. It remembers the Cambrian explosion of CPU architectures, twelve-bit bytes and everything like that. I wonder if it is possible to codify some pragmatic subset of it that works nicely on currently available CPUs. Cause the author of the piece goes back in time to prove his point (SPARCs and Alphas).
That cast is valid. Spec does not guarantee same bit sequence for resulting pointer and source pointer. But as the cast is explicitly allowed, it is not UB. Compiler is free to round the pointer down. Or up. Or even sideways. All ok. Dereferencing it — indeed not ok. But the cast is explicitly allowed and not UB.
Pointer casts changing pointer bit sequences is common on weird platforms (eg: some TI DSPs, PIC, and aarch64+PAC). And it is valid as per spec. Pointer assignment is not required to be the same as memcpy-ing the pointer unto a pointer to another type.
You misunderstood the spec. No promises are made that that cast copies the pointer bit for bit (and thus creates an invalid pointer). Therefore, your objection to invalid pointers is null and void. :)
I'm not assuming anything about bit representations. In this case, the spec language is quite clear and unambiguous.
6.3.2.3 paragraph 7: A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned[footnote 68]) for the referenced type, the behavior is undefined. Otherwise, when converted back again, the result shall compare equal to the original pointer. When a pointer to an object is converted to a pointer to a character type, the result points to the lowest addressed byte of the object. Successive increments of the result, up to the size of the object, yield pointers to the remaining bytes of the object.
This is a subsection of section 6.3 which describes conversions, which include both implicit and conversions from a cast operation. This language is not saying anything about bit representations or derefencing.
I happen to be wearing my undefined behavior shirt at the moment, which lends me an extra layer of authority. I'm at RustWeek in Utrecht, and it's one of my favorite shirts to wear at Rust conferences. But let's say for the sake of argument that you are right and I am indeed misunderstanding the spec. Then the logical conclusion is that it's very difficult for even experienced programmers to agree on basic interpretations of what is and what isn't UB in C.
I do not see there a promise that the cast will produce an invalid pointer, nor anything prohibiting the compiler from rounding the pointer down, thus producing a valid one. “Converted” does not require bit copy. I don’t see how this interpretation is against any section of the spec.
I also do not see any requirement in the quoted text that the casted pointer be dereferenced before noting "the behavior is undefined".
In practice performing a cast doesn't really do much until you dereference, but without a carve out in the spec, it does really mean "the behavior is undefined".
People interested in alternatives to Lean should also look at Metamath. It has nowhere near the adoption that Lean is getting, but is holding its own in [100] theorems results.
It has some advantages and compelling properties, not least of which is that it's very simple, so much so that there are many implementations of checkers; most other proof systems are ultimately defined by a single implementation. It's also astonishingly efficient — the entire database can be checked in less than a second. Set theory is also a familiar foundation for mathematicians, though the question of which is a better foundation compared with type theory is very controversial. Mario Carneiro pushed forward the development of Metamath in his thesis [0].
There are downsides also, including junk theorems, and automation is weaker. It's possible that types really help with the latter. Even so, I think it's worthy of study and understanding.
A different approach, refining the square root based sigmoid with a polynomial, is in my blog post "a few of my favorite sigmoids" [1]. I'm not sure which is faster without benchmarking, but I'm pretty sure its worst case error is better than any of the fast approximations.
You can add to this the Apple terminology, which is simdgroup. This reinforces your point – vendors have a tendency to invent their own terminology rather than use something standard.
I have to give it to Apple though in this case. Waves or warps are ridiculously uninformative, while simdgroups at least convey some useful information.
Indeed. I try not to use the word "native" these days as it has such ambiguous meaning. I also have thought for a while that Windows no longer has native UI, only legacy (Win32) and a rotating carousel of mostly-failed attempts. There have been a few HN stories in the last week that bear me out, notably [1]. Mac of course is in better shape, as AppKit and SwiftUI are both viable (and interop well enough).
I found this article about as compelling as all the other attempts at identifying him. Half of the cypherpunks (I was pretty active) had the same set of interests in public key cryptography, libertarianism, anonymity, criticism of copyright, and predecessor systems like Chaum's ecash; we talked about those in virtually every meeting.
The most compelling evidence is Adam Back's body language, as subjectively observed by a reporter who is clearly in love with his own story. The stylometry also struck me as a form of p-hacking—keep re-rolling the methodology until you get the answer you want.
It's entirely possible Adam is Satoshi, but in my opinion this article moves us no closer to knowing whether that's true or not. He's been on everybody's top 5 list for years, and this article provides no actual evidence that hasn't been seen before.
What struck me in particular was the fact the reporter noticed that Back had theorized how to evade stylometry. Obviously, if one of the people in question had specifically come up with ways to evade methods, you’d want to re-roll those methods to account for that.
That, alongside a number of other tidbits (Back’s activity and inactivity patterns lining up with Satoshi’s appearance and disappearance, his refusal to provide email metadata, his financial incentive to hide his identity as Satoshi under US securities law) makes the case a lot more meaningful than just “likely p-hacking.”
>his financial incentive to hide his identity as Satoshi under US securities law
I don't think you can attribute this to financial incentive. The actual Satoshi could forfeit 90% of their BTC and still have more than they could know what to do with.
At those kinds of levels I can see personal security being a higher consideration.
Either way it would give no indication who might be Satoshi because all candidates would have a similar incentive if they were Satoshi, and you are measuring the absence of information.
why does everybody assume that whoever is Satoshi still has access to their wallet? It's absolutely possible whoever is Satoshi has simply lost the key.
We're talking new technology where you're running fast and loose. It's absolutely possible, and I'd say a big reason why someone would not want to admit to being Satoshi.
I'm Satoshi, but I also lost billions because I messed up a Debian upgrade.
Further, no one would believe them, and they'd still endlessly be a target for criminals. No benefit to revealing any information beyond mild dismissals, IMO.
> I'm Satoshi, but I also lost billions because I messed up a Debian upgrade.
That would be very funny. I used to own a whole bitcoin when it was worth nothing.Didn't think it would be ever worth anything and formatted my hard drive to change distro.
I commented elsewhere in this thread theorising that Satoshi could be the work of both Finney and Back. If that has any basis in reality, then it stands to reason that perhaps the wallet is locked away in a trust or at least legally unobtainable until certain conditions are met (e.g. Adam Back's passing). I can imagine a scenario in the future where a law firm makes a press release confirming they're in possession of Satoshi's wallet and have been instructed to liquidate and donate its proceeds.
I think this is plausible as well. One of the emails used by Satoshi was tracked to CA (where Finney lived), the original paper talks in plural "we" (fwiw), and the Dorian Satoshi person lived in CA and could have been an inspiration for the name (if Finney had come across him somehow) since he was a very private, anti gov person (not saying he had anything to do with BTC)
Or what if Satoshi deliberately destroyed their key?
The motivations behind Bitcoin were clear.
All the wealthy people I know don’t really do it for the money. The money is the gauge or the metric they use to judge how well they are playing the game but what motivates them is the love of the game and their sense of purpose.
If someone was to truly believe that Bitcoin was going to be a gold/USD/Eurodollar/swift etc. replacement then their metric of success isn’t money if they got in early.
Also I think that people discuss this stuff in a very narrow minded way. “Is it one person or multiple people?” Maybe it was one person to begin with then others joined in to contribute under the pseudonym.
Given all the available information (including the DHS worker revealing that Satoshi was identified by the USA government and he was multiple people)[0] this is the most likely case.
It's entirely possible that Satoshi has deliberately destroyed the keys, but lost them? I doubt it. All these early cryptography guys were very conscious about keeping their keys secure, they discussed it endlessly.
Bill is donating his money for 2 reasons; taxes and an attempt to make himself look good similar to Rockefeller and Vanderbilt. Microsoft didn't get where it was by playing nice but it is amazing to see how quickly that was forgotten. I think it was working too except that his friendship with Jeffery was exposed, we shall see.
One other factoid that the reporter did not mention: if you read through all of the cited papers in Satoshi's original BTC paper, only one of them is similar in layout, language formality levels, citation setup, and length: Adam Back's Hashcash
Personally, if someone accuses me of lying, but I am actually telling the truth, I immediately start acting like a liar. It's really embarrassing and hard to explain. I can't believe such a seasoned reporter is leaning so hard on "his face went red."
What's also worth noting is that they were not alone in the room, talking privately. Everything being said could presumably be heard by Back's business associates as well. Some of the questions could well be enough to cause embarrassment or unease on that account.
Yea pretty similar idea to a polygraph test which for years was called a "lie detector."
In reality, they measure a bunch of things that may indicate lying, but they are just as likely to indicate that a person is nervous or reacting to the fact they're being tested at all.
They're typically inadmissible in court these days, however, there is still a pretty solid amount of blind trust in their results.
That part of the article gives a similar "lie detecting" hypothesis, just without the machine.
It did make me think - if he seems nervous under this questioning, it could be because he's actually Satoshi. Or it could also be because he's thinking something like, oh god, if this jerkoff convinces a bunch of people I'm actually Satoshi, all of the businesses I've worked so hard to found will collapse, I might be convicted of crimes around lying about it while founding these businesses, I might get targeted by any number of criminal gangs or even nation-states who will do all kinds of torture to me and my loved ones and will never believe that I'm not actually Satoshi and don't really have a secret stash of a bazillion Bitcoins.
Naturally, this journalist doesn't seem to care much about any of that, or that it wouldn't really change anything at this point besides making the life of whoever it actually is hell.
In fact, we are incredibly bad at telling lies from the body language of people we don't know well. Pretty much all the "well known" tells are sheer and utter bullshit that at best tells you if a person is stressed. That may or may not mean they are lying, but unless you know that person well enough to know if they have specific tells that correlates with lying for them, your odds are poor.
Just a shot in the dark but any chance you grew up in an intensely religious household?
I grew up evangelical and I've noticed this tendency in myself, and saw the connection to how the authorities at my school or church basically demanded dishonest performances or apologies under threat of physical punishment. Several friends over the years have said roughly the same, so I have an armchair theory this is pretty prevalent for that sort of childhood.
If you were around those circles, a lot of the "signals" in the article just look like the shared baseline culture rather than anything uniquely identifying
I actually think the most compelling evidence is the fact that he was one of the first people to get rich from it, which also explains why he never had to touch his vault of coins.
This is a perfectly reasonable question, and I think there are two aspects to it.
First, one of the research questions tested by Xilem is whether it is practical to write UI in Rust. It's plausible that scripting languages do end up being better, but we don't really know that until we've explored the question more deeply. And there are other very interesting explorations of this question, including Dioxus and Leptos.
Second, even if scripting languages do turn out to be better at expressing UI design and interaction (something I find plausible, though not yet settled), it's very compelling to have a high performance UI engine under a scriptable layer. I've done some experiments with Python bindings, and I think in an alternate universe you'd have apps like ComfyUI as high performance desktop app rather than a web page. Also, the layering of Xilem as the reactive layer, backed by Masonry as the widgets, is explicitly designed to be amenable to scripting, though to my knowledge there hasn't been a lot of actual work on this.
The way Vello/Masonry/Xilem are split projects is partially what got me interested in it (and in turn caused me to post it to HN), as well as the reactive architecture of Xilem.
I do believe a garbage collected interpreted language would work best for UIs.
Something like Vala (for gtk) but with a runtime/vm.
python-qt has shown to be a very strong combination. My issue with such solutions is that packaging a python application to the end-user can bloat binary size.
I also think GTK should get some credit in that space, because due to GObject introspection it's easy to interface with GTK with any language.
* It's a genuinely hard problem
The state of GUI on Windows is a total mess, very disappointing considering the relative importance and resources that Microsoft has. SwiftUI was a success (Apple is uniquely good at this stuff), but the transition from Cocoa is still not complete. A large part of the reason why it's so hard is that the requirements for different apps vary widely; I think we are spoiled by the relative cohesion
* The infrastructure is in disrepair
A UI is built on top of lots of infrastructural pieces, obviously including graphics and compositing, but also text, accessibility, input handling, and many other things. When you look at support for those layers across platforms, it's like picking up a rock and seeing the bugs crawl. Take compositing: Windows and Mac have excellent compositors, Android and Linux much less so. But even there the features don't line up, Mac doesn't support incremental present (they don't really need to, considering how beefy their chips are, but it's really important on low end Android).
So a lot of the challenge is working around the brokenness across the various platforms. But, good news, there is really excellent progress on all these fronts. We now have solid text layout in Rust, a clear winner on accessibility, and even poor winit is making slow, steady progress.
I'd also like to say, by contrast the web has really been investing in infrastructure, and hides much of the lower level pain from developers. I think that's a major reason Electron is winning so much.
* The computer science is not quite done
We're still in an exploratory phase to figure out the best patterns for writing Rust UI. At the core of that is reactivity, which is at heart incremental computation. Most systems are converging on a hybrid of something generally React like (coarser grain reactivity) with fine-grained signals. I'd like to think there is a Right Answer here and that it's possible to find it.
This feels to me a bit like async. The foundations for async Rust were laid 10 years ago, but it still doesn't feel fully baked. I've seen some exciting recent work about improving the confusing Pin mechanism with something more principled. We'll get there, but it takes time.
I make three predictions:
* Rust UI will continue to improve, as the infrastructure is built out, we try more things, and projects mature. But not quickly.
* If we thought we had a lot of Rust UI projects before, wait til we see what AI wreaks. I predict we'll see dozens of vibe coded Rust UI toolkits.
* In the longer term, we're going to have Rust UI anyway, as browsers are increasingly going to be rewritten in Rust, and apps will be built on Web technology. And that's not just Electron, the modular browser approach pioneered by Blitz is also promising.
reply