I've been meaning to make a "GNU Radio in the Browser" (well, gnuradio-companion-like) for my RustRadio project to build flowgraphs without coding, but not gotten to it yet.
With wasm, I see a future where the browser and thus web technologies are a UI toolkit for a Linux desktop environment. It already is, people hardly use GTK and qt anymore except for desktop environments or embedded like on cars due to performance limitations. It would be cursed to see a browser running within a browser. But then replacing a desktop environment might be the limit of replacing GTK qt and other UI toolkits with web technologies, making it unnecessary and opposite to the reason people use Linux which is performance
I agree. Browser APIs don't have as much coverage as native APIs, but I would say that by far most UIs should be in the browser nowadays.
Quake can run in the browser, so in my opinion so can the likes of Photoshop. Maybe the latest AAA game is a different beast, but that's a tiny edge case.
Websites instead of apps on mobile is something that basically always sucks, but I don't see the same on desktop.
Just build your UIs in WASM already. :-)
> It would be cursed to see a browser running within a browser
> Websites instead of apps on mobile is something that basically always sucks
I find it's the opposite: on my computer, I want native apps, but on the phone, it is very hard to manage a large collection of single use apps because I do not have a keyboard to quickly navigate between them.
If you are on an iPhone you can add a website to the Home Screen and it functions as a dedicated app essentially and the opened instance is treated separately from safari
Uhm, I am saying that I do not want a 100 apps (website-based or native) on my phone because this is hard to manage without better human-computer interfaces like a big screen and physical keyboard.
So I am not sure how making a web page into an app actually helps me?
When they are a web page I frequent, typing a few letters in the browser URL bar gives me the URL to click on and get there.
The benchmarks are from GCP, where the vTPM is implemented in the hypervisor rather than on something that's plausibly an 8051[1]. Doing this on actual client hardware is going to be a bunch slower.
[1] Typically ARM these days, but most system vendors aren't picking TPM vendors based on performance
What mjg59 says. The benchmarks are against a vTPM, that was what I had access to, and it's the environment I'm implementing the RATS side in.
Worth adding that not every outbound connection needs to go through the TPM (IMO). It's for the handful of services where the machine-identity actually matters, a secret store, or an HSM releasing key material onto an attested confidential VM, in my case.
You didn't really go into actually verifying the machine identity - obviously if you have a trusted mechanism to do that in advance then that's easy enough, but otherwise you'd want something like https://github.com/google/go-attestation and then to use control plane APIs to identify the vTPM EK to tie the TPM to the VM.
I'd suggest you look at it as funny and not annoying: IKEA in London, being a very multicultural place, likely has many non-native English speakers as well!
When all else fails, you can always go back to the basic international language of gesturing, pointing and acting out the use of something to get to your point. (Or more boringly, point at the name on your phone)
You could also try adapting pronounciation to what they might expect first, and then if you establish a friendly conversation, offer the real Swedish pronounciation next.
It sounds like that would be very much what use of Swedish names in a global brand should invite, and not annoyance for Swedes :)
As a related anecdote, I found it surprising when I moved to Switzerland decades ago, that speaking high German wouldn't really work with foreign-looking shop assistants - they'd only speak and even understand Swiss German.
> you can always go back to the basic international language of gesturing,
Doesn't really work for the kind of products they sell. E.g. going to the spare parts place and asking for a replacement part for Mörbylånga or Nackanäs. And I don't know the international gesture for a table. Besides, they have many tables.
I don't think saying "Bläddra", and signing that you're flipping through a book, helps at all either.
> You could also try adapting pronounciation to what they might expect
Right. This is what one has to do. But it feels like if you were to go to Russia and slowly and loudly say "I-ski want-ski a-ski table-ski". Except, you know, not offensive because I have the objectively right way to say it and the staff doesn't.
I'm not saying it's hard to do, but since once you know a language you pretty much cannot go back to hearing and reading it as noise, I stand by that it's a bit annoying to need to simulate how someone else would mispronounce it.
And this is unlike someone experiencing their names constantly mispronounced, because the people who get it wrong literally work for IKEA.
For comparison, say there was an English store in Netherlands, and you would have to look at the spelling every time in order to "simulate" which "s" should become "sch" to make the staff understand you. Saying it the dutch way may, to you, become a tongue twister.
> It sounds like that would be very much what use of Swedish names in a global brand should invite, and not annoyance for Swedes :)
You'd think so, but while a great brand, it causes practical annoyances sometimes.
They have a great selection of products. You could say they have a smörgåsbord of products. Or as you'd have to say in English to be understood, a schmoargoesboard.
> When Mötley Crüe visited Germany, singer Vince Neil said the band could not figure out why "the crowds were chanting, 'Mutley Cruh! Mutley Cruh!'"
But like those German speakers assumed German orthography, English speakers will assume English orthography when presented with Swedish words.
Only foreign words learned by sound have a chance of getting pronounced correctly, e.g. croissant or Djokovic... maybe even Smörgåsbord?
If there were a British furniture shop operating globally and using placenames for products, British people would have trouble asking the locals for HAWICK (hoik), LOUGHBOROUGH (luffburra), FROME (froom) or YNYSYBWL (anissabul)
They didn't assume German pronunciation without reason. The umlaut dots aren't for decoration in German and ä, ö, ü only sound one way - including in Swedish, which has ä and ö, too. There is no ü in Swedish maybe because the Swedish u sounds like the German ü already (and shifting it further would just make it sound something like an i).
I was surprised at a Jysk in Spain where I used the dialect pronunciation of a Norwegian city (saying Læknes for Leknes) when buying chairs with that name, and the girl not only understood me but used close to the same pronunciation when asking someone to get them from storage
I once mentioned a street name to a Dane, who didn't understand me, and when I showed her the written name she pronounced it the same way. Maybe sometimes people have weird assumptions how foreigners are supposed to sound.
In this case you would understand me if I pronounced "ABBA" the Swedish way, so the IKEA scenario doesn't happen.
Not that I do say it that way when speaking English, just like I don't say my own name in the Swedish way.
But if "ABBA" had been named "ÄBBA"[1] (to be clear, that's not "A with an accent", that's a completely different letter) then I would pronounce it "ÄBBA". And it would be annoying. But at least other music fans are not employed by ABBA, so shrug, Mötley Crüe.
I would imagine that a Chinese person would be annoyed if they had to refer to their president as "Eks Eye" when speaking English.
Or do you mean the accents in the ABBA songs?
[1] which would be confusing, all else equal, because it would be pronounced like Ebba in Ebba Grön, another band.
"If I was a rich man", "I feel good", "we don't need no education", the repetition of "and their bombs" in Zombie, "Me and Bobby McGee", the weird "this" pronunciation in "Sweet Dreams", making people mishear it as "these", etc… (just off the top of my head)
The (deliberate) almost nonsense in Nirvana songs, too.
It is funny (heh) that the "funny" in ABBA's "Money, Money, Money" and "Does Your Mother Know" is a misuse of the word that my mum makes all the time when speaking English.
Other than that, non-native English speakers having an accent is not really something to have an opinion about. I think most Swedes probably don't hear it, and think that the Skarsgårds don't have a Swedish accent, whereas I can almost always spot a Swedish accent immediately.
I simply assumed that if someone gets annoyed when local employees cannot speak the primary language of their foreign parent company (a company decision btw), that same person would also be bothered when foreign singers sing or speak in unnatural, non-native English.
> local employees cannot speak the primary language of their foreign parent company
No, I said they don't recognize the names of their own product when spoken correctly. I did not say they need to be able to say it correctly, and absolutely not that they speak another language.
Reference counting is a different model. Many papers have explored the differences and similarities, and your comment leaves so much out that it cannot even be said to be true or false.
I'd say GC is always the fastest to free objects within the main code path. Literally zero instructions.
Java pioneered this garbage collection stuff because you had cycles of references. You don't need to have cycles. WeakRef is a much better thing now. All you need is reference counting, and you don't need any garbage collection at all. When the reference count reaches 0, you destroy the object and free up its memory. It's far more predictable than GC, too.
And GC isn't "the fastest" to free objects, it has to walk a graph. The fastest is actually arena allocation and then just dropping the whole thing. But that's exactly what owning an entire container of objects can do. If you have a doubly linked list, for example, A[n] -> A[n+1] but also A[n+1] -> A[n] but neither of those should be a strong reference to prevent reclaiming. Instead, the container of that doubly linked list should be the one having a strong reference to its items.
I understood your first comment without expanding on it like this. You also don't need to explain what reference counting is.
> GC isn't "the fastest" to free objects, it has to walk a graph.
No, you don't inherently need to. And what I said is that it's super duper fast to produce garbage. I did not say that actually freeing the underlying memory, or any other cleanup, was fast.
I'm not even arguing for GCs, here. I even think GC languages tend to become tech debt generators, as garbage is not addressed until it's a really complex problem with no good solutions.
Lisp pionered GC, and all its flavours, followed by CLU, Smalltalk, Cedar, BASIC and all its flavours, Modula-2+, Modula-3, Oberon, Oberon-2, Component Pascal, xBase/Clipper, Standard ML, Caml Light, Objective Caml (now OCaml), Miranda, Haskell,...
> I'd say GC is always the fastest to free objects within the main code path. Literally zero instructions
True, but reference counting or free need not be far behind. They can append the pointer being freed to a per-thread list (⇒ no locking needed) that a separate thread that does the actual freeing periodically claims and then iterates over to actually free the objects.
Disadvantage is that memory usage goes up a bit because the actual freeing is delayed, but that (likely) is less so than with a garbage collector.
Which GC? Java is like C and C++, plenty of implementations to chose from, including reference counted implementations in the past [0], arenas and real time GC for embedded deployments [1].
People love to complain about Java without understanding the ecosystem.
I don't claim to be an expert on it, but I'm not uninformed either. Yes, I'm aware of many implementations and variations. With various talks from vendors that rant about "a mostly-pauseless GC is one that sometimes pauses!! Ours is a pauseless compacting GC".
But per my linked blog post (that you did read?) I do go into Java language problems that make GC impact worse.
The care and feeding of the Java runtime environment, entirely a self inflicted problem, that goes from selecting one and tuning ALL its parameters, kind of proves my point. It's not just knobs, but whole runtime environments. If there had been "a best one" with no knobs, that "just works", then fine. But there isn't.
Ignores that Java had escape analysis years before Go happened, granted the quality depends on which JVM is actually used, e.g. GraalVM is better than OpenJDK, and there are others to chose from.
Ironically Go designers got educated why GC knobs are relevant, and why a single GC doesn't solve all use cases.
And it doesn't need an advanced GC, so Green Tea rewrite was wasted work?
You can do off heap allocation in Java with Unsafe, JNI, ByteBuffers, and more recently Panama. This not taking into account the APIs provided by real time Java specification.
Finally with Valhalla design now being merged into the language (Java 28+) we get explicit value types, while Go still needs to rely on compiler warnings for failed escape analysis.
And the remaining Java rant could be further deconstructed.
However your blog clearly points out where you stand in regards to Java, so maybe some unwillingness to learn the ecosystem was part of it.
Anyway. This is all a bunch of irrelevant details. The original point I had made was that you don’t need GC at all, if you just have a canonical direction for references and make sure that the other directions have only weak references.
> Ignores that Java had escape analysis years before Go happened
Yeah, because I don't think that matters. I do assume that Java has most of the state of the art GC work applied to it. Partly because it produces more garbage because of language decisions.
> And it doesn't need an advanced GC, so Green Tea rewrite was wasted work?
One of the problems with GC is that it means forever working to come up with the "sufficiently smart GC". It was Java's original sin wrt memory, and why it did not mind producing so much garbage.
But in my opinion Java has illustrated very well that there's no end to pursuit of the perfect GC. And being runtime behavior I find it a worse one-way door choice than Rust trying to find the perfect borrow checker.
But no, it's not wasted work. Just like with Java improving GC and allowing programmers to produce less garbage (I shall resist making a pun here) will save many dollars of electricity, battery life, and human waiting time.
> However your blog clearly points out where you stand in regards to Java, so maybe some unwillingness to learn the ecosystem was part of it.
You could say that. You could also say that I won't aim to become a connoisseur of the many flavors of poop that Java is working on. The point of my is that it's clear from history and evidence that Java is poop, so finding the best tasting poop is not really interesting, nor in going in to too many details about the nutmeg aroma and polished shine a particular ball of next gen GC delivers.
Life's too short to continue tasting what is already known to be poop.
> In Rust you pay for it by arranging your program in a way the compiler can verify.
I disagree with this. The sentence implies that this work is done in order to make the compiler happy, where my experience is that it forces the programmer to actually get it right.
I had an "aha moment" when I was frustrated at failing to express my intent to the compiler, and suddenly realised that the reason I couldn't "just say the magic words" was that my object ownership design was inherently flawed. I had to make large changes not to make the compiler happy, but to actually have a coherent design.
So no, it's not about what "the compiler can verify". That's like saying "my lawyer won't let me do this". No, your lawyer is your employee, not your boss. They're just saying that if you do this, then you may go to prison. It's not the same thing.
("unsafe" is the Rust way to go "thank you, legal department, but I'm making a business decision to take this risk. Your concern has been noted")
I understand what you’re saying, but I read that phrase in a different way.
Let’s say you have two ways of doing the same thing: both work, both are legit and neither introduce GC bugs. The only difference between the two is that one can be verified by the compiler while the other can’t, so you are stuck with solution no. 1 although both would work.
To phrase it differently: the code that gets verified by the compiler is safe, but is all safe code verifiable by the compiler?
I’m not implying that’s the case, but that’s what I feel the author is saying.
> To phrase it differently: the code that gets verified by the compiler is safe, but is all safe code verifiable by the compiler?
Right. And this reduces to the halting problem, so in theory the compiler cannot know that all safe code is safe.
In practice, I'm saying that not just syntactically, but in your code's design, the compiler is more likely to be right. It's a bit like Chesterton's fence. You can bypass the lifetime checks if you just have the confidence to say "yes, I'll use `unsafe` here and it's fine because these reasons". As you're writing your "SAFETY" comment, you may very well find yourself not so confident anymore. And indeed, often this compiler-induced "stop and think" prevented you steaming ahead with a bug.
Now, the borrow checker is not perfect. I don't know how far away from "all but NP-complete cases" it is. My experience is that it's almost always right, and I've only had to put a seemingly needless "drop" statement to placate it. But they're working on it. A new one is coming: https://daily.dev/posts/rust-s-new-borrow-checker-is-coming-...
In any case "by arranging your program in a way the compiler can verify" I think is not accurate, because the overlap between "correct" and "compiler can verify" is nearly complete, though yes the latter is a strict subset of the former. In other words I don't write Rust to make the compiler be able to verify it, but to make it correct. And nearly always that means the compiler can verify it too.
To the point Polonius is finally landing, and while it is better than current NLL, there are some issues it introduces, and it is still far from production.
Because of this "halting problem" compromise, I prefer the approach other languages are pursuing, keeping some form of automatic memory management, while improving their type systems, like Swift, Chapel, OxCaml, Scala 3, et al are pursuing.
I've had that moment in Rust too, where there was no composition that effected what I wanted, because supporting that model would have meant a very different backing data structure. However in that case I actually didn't care about the kind of correctness problem it was saving me from.
I've also had the converse experience, where I know full well that the structure I'm trying to impose is correct and quite efficient, but its part of the space that rust doesn't cover.
Rust is great. It's a noble attempt to bring a degree of correctness to a problem space that suffers from a great deal of slop. But to pretend that the model is complete, or that the design decisions that were made are perfect in every way, is just wrong. That the rust compiler and runtime can't support my construct isn't really an absolute value judgement on that idea in the first place. The rust compiler isn't really an oracle that tells you whether something is right or not in an arbitrary value system.
Right. The borrow checker is not always right. Just almost always right. It's not perfect (because halting problem), but… well I already said the rest in https://news.ycombinator.com/item?id=49287460
Still, I don't write Rust code the way I do "to make the compiler happy", but to make it correct. And sometimes it's correct to drop some "unsafe" because gosh darn it, you know it's fine this time.
And you're probably right for the cases you're thinking of, where Rust wouldn't let you (at least without unsafe). And maybe you're 99% sure about that.
But for every 100 changes we’re 99% sure won’t cause an outage, one will…
(also future changes may invalidate assumptions you relied on, of course, making it no longer true)
Do you have some examples you can share where you think Rust prevents you doing the right thing? The ones I run into tend to force me to think of the edge cases, and usually those edge cases don't even have a right answer.
this one may actually be solvable, but I kinda timed out on it. okay, so I'm doing distributed systems, and my primary abstraction is a large stream that I'm using to connect components across machines. its kind of mandatory that I implement back pressure for these streams, because awful things can happen if I don't.
ok, I have a large local container of records that I want to stream over a back pressured channel. now we clearly have a problem that the iterator needs to be long lived, and I don't really want to serialize all accesses to the collection for a streaming operation that may never terminate.
for this particular domain I don't actually care about serializability of the iterators view of the collection. I clearly don't want the container to be left in an erroneous or inconsistent state, but otherwise anything goes.
all the iterators for all the standard rust containers have lifetimes bounded by the container (batch), and because they all represent internal state, they all have to be mutable. and in this case they need to be async also.
I don't think there is an 'idiomatic' way to represent that access pattern, and it kind of necessitates writing ones own container. if there is a good answer to this I'd be curious to hear it, but I consider this one of the major personal failure modes for rust, which is 'oh, yeah, well, in order to figure that out to need to understand [long list of compiler instristic property types and runtime behaviour], which isn't super pragmatic.
since I'm here, I've already wasted words here talking about the dismal async situation, but I think more important to me as a systems programmer is the lifetime abstraction. It think its great to put a name to it and try to put rules around lifetimes - these are traditionally implicit things that we reason about _outside the program text_, and that's a real bother. however everything I do is state management, and the lifetimes of those states (files, connections, higher level sessions) don't directly correspond to the lexical calling stack. the only tools that rust gives me is Arc, which some with a whole set of busy caveats, or trying to thread several lifetimes through the entire call path - a road that I've been down and abandoned for readability and maintenance.
now you can argue that rust would prefer that I use a thread per object, and while that might be workable, that a pretty strong and side-effecting constraint to apply to all of the programs in my domain.
anyways I ended up keeping the last key issued, and for every new record, paying the logn cost to get to approximately where I was perviously. which brings up another general complaint. as imperfect as it is, sometimes I want to just stand sometime up and look at it. I don't want to spend 3 weeks coming up with sharing policies and structures that work well with rust. I want to look at it and measure it and count its defects in my head and decide what to do next. in rust I kind of have to decide up front what I'm building, and while that might be an excellent thing to encourage in some contexts, I don't think it is in all contexts.
I think there's a lot of "the devil is in the details", here, and I'm going to be respectful enough to not start a bunch of "why don't you just…".
It does sound like a thing where if you'd written this in C++, then you could have done it much easier (which is my experience), and then either also, or later on when the state of the invariants are no longer in your working memory, one of those invariants would be violated and memory start corrupting (also my experience).
E.g. in a C++ vector you can push_back() without invalidating the iterators iff there's enough capacity in the vector. Though if some code saved the "end()" iterator (e.g. concurrent for_each), that's broken. std::vector doesn't permit that use case, but does not prevent it. I prefer it being prevented.
I would consider the extra work to be worth not finding that problem in production, later.
Ideally what you want could be accomplished by just (oh no, there I go) finding a single place to punch a hole, put an "unsafe" there, and explain why it's actually fine to create some inner mutability or whatever is needed there.
The huge complexity baggage, and the amount of working memory you need to reason about async, is unfortunate though, and I won't defend it. But at least it fails closed if you get it wrong.
> I disagree with this. The sentence implies that this work is done in order to make the compiler happy, where my experience is that it forces the programmer to actually get it right.
Haskellers say the exact same thing. :P Personally, I'd much rather get shit done and don't appreciate tools "forcing" me.
Something suspiciously absent from this article is addressing whether some of these are in fact human visitors, but humans issuing chatgpt or similar queries instead of going directly.
Is it really a bot if it's in response to a human asking for some aggregate information about charities, triggering a web search and then following the result links to get details for the human? Well, clearly yes it is, but it's a very different proposition from this article's implication that "they have no throttling on their scrapers"[1].
> Challenge 46 datacenter ASNs. Humans don't browse from AWS.
People who have workstations in the cloud do.
> The bots use 99% of the bill and I pay 100% of it.
Running a site this way is always a wallet-DDoS risk.
[1] though yes, by far most will be pure automation with no human in the loop. It's an assumption on my part, but feels like a safe one.
> Something suspiciously absent from this article is addressing whether some of these are in fact human visitors, but humans issuing chatgpt or similar queries instead of going directly.
That's not absent from the article, it's right there in the section titled "The Claude ratio". ChatGPT, Claude, etc. use different user-agents for scraping vs user-initiated requests, and the author notes that user-initiated requests were an absolutely miniscule fraction of the total traffic.
For the age of the Internet, running a website metered is a pretty new phenomenon.
Or at least this directly metered. 20 years ago maybe you would pay for your monthly 95th percentile bandwidth use. Not saying that was great either, but it was certainly more managable than what's common now.
In a "realtime system", sure. But for almost all workloads programs have to deal with overshooting. Like, maybe CPU overloaded or swap intensity caused that second to "disappear". On almost all workloads you can't just assume that you'll execute on every single second.
And if you do need to be scheduled on every second, well you always needed to use a monotonic time.
Negative leap second should only cause measurements to be off by a second, at worst. Added leap seconds means time goes backwards, which is worse.
That's exactly what I see happening when a leap second is ADDED.
A leap second is added. The system goes "oh shit, I'm a second ahead", and subtracts a second. And that's how you get a negative duration and exactly this problem.
Whereas if a leap second is subtracted, you get charged for an extra second.
> Direction finding equipment for determining bearings to specific electromagnetic sources or terrain characteristics specially designed for defense articles in paragraph (a)(1) of USML Category IV or paragraphs (a)(5), (a)(6), or (a)
ITAR part 121.
The "specifically designed for defense" probably makes this OK, but IANAL.
I've set off time to blog about getting my broadband RF scanner (connecting to USRP B200 via WebUSB) to work in WASM.
https://rf-survey.habets.se/
It's basically https://blog.habets.se/2026/08/Broadband-RF-scanner-revisite..., but in the browser.
I also have an AX.25 decoder (https://thomashabets.github.io/ruwasm/) and plain old FM receiver (https://cement.retrofitta.se/tmp/rtlsdr-fm/) already. The latter two work with RTL-SDR, also via WebUSB, so no software installs or setup required.
I've been meaning to make a "GNU Radio in the Browser" (well, gnuradio-companion-like) for my RustRadio project to build flowgraphs without coding, but not gotten to it yet.
reply