thomashabets2

While we may not disagree on the base facts, I don't think that's a fair characterization. First of all, you say that there have never been solar panel subsidies, which of course there have been. So the advantage has most certainly been offered to non-nuclear.

By law, opting in to "green energy" on your personal electricity means to have a definition that excludes nuclear, so that's government steering of the market towards non-nuclear green energy. Certainly qualifies as incentive, if not downright subsidy by manipulating market forces. (I even contacted my energy provider saying I would gladly check a box if it included nuclear. They said it was out of their control)

Of course on oil lots more has been spent fighting over the resources. For a given country the cost of acquiring the resources may be more political than directly monetary. But I don't think you're defending fossil fuels, so I probably don't need to argue that being controlled by Russia has a cost.

Now, if nuclear is not economical as base load, I'd like to see a comparison with solar & wind for base load compared to nuclear. And it should be a calculation for the (very nearly) 100% use case. So comparing like for like. The cost of wind&solar is extremely different if aiming for 90 or 99.999%.

Some Greens say "shrug, what's so bad about power outages?" (yeah, good luck with that). Some say "we'll just import in the greater European grid!" (greenwashing).

> not economically viable without significant government subsidies.

Nor is gasoline or road maintenance. I'd like to price in those externalities first.

Oh, and as for the left-ish opinion in this issue. IIRC only Greens and Communists were actually against nuclear. The big one (Social Democrats) manifesto could be summarized as "Well, we're pro-nuclear, but we know we have to give that up because we need Greens & Communists to be able to form a government". It was very transparent.

As long as the overall strategy has a plan for dunkelflaute which isn't just "oh then we'll just import (German coal power)", then sure.

> bogus national security grounds.

Nobody would sabotage energy infrastructure in or near international waters, you mean?

Every single word you said is wrong.

I know HN comments should be more constructive than that, but your comment is setting all these trumpesque fires in the form of lies, that no constructive debate or rebuttal would be useful. You would not be convinced, and anybody reading the back and forth would be under the misapprehension that "the truth is probably somewhere in between".

> [the two parties] conflate civilian and military use of nuclear energy

I would never associate these two parties with competence or intelligence, and there certainly are people who think that a power plant is basically a bomb.

But no, their rhetoric against nuclear power today is at least ostensibly environmental. Well, as it's becoming clearer and clearer to everyone that environmentally it's at the very least the least bad option, they are shifting into trying to make it about economics. Of course completely ignoring that they want to price in (like in this thread) insurance with nuclear, but don't want to price in environmental damage of the alternatives.

Between 1987 and 2006 "the thought crime law" made it illegal in Sweden to even think about constructing a nuclear power plant. https://sv.wikipedia.org/wiki/Tankef%C3%B6rbudet

How much does nuclear power cost? Well, it was literally illegal in Sweden to run those calculations until 2006. Could criminalizing thought for decades maybe drive up the costs, once the law is repealed?

> New hydro dams?

Unlikely. It's already built out where feasible and economical. And besides, the Greens would block new hydro at scale because of their environmental impact.

> How could the replace the current 25% of nuclear electricity?

Most common argument I see is "we'll just import it", which is just greenwashing since that comes from fossil fuels.

> ‘Peaceful’ Sweden once sought nuclear weapons.

I don't see the contradiction. USSR took 10% of Finland in living memory, hell that was just single digit years before Sweden started looking into becoming a nuclear state. The Baltics were under USSR control too, and during the cold war they (USSR) seized Swedish ships in international waters and killed and otherwise "disappeared" the crew.

I find the article you linked complete garbage. It's viewing 1940s defence choices through a 2020s post-nonproliferation treaties and post MAD game theory lens.

But even if we do that, would it be un-peaceful to have deterrence? Sweden preemptively surrendered to Germany in WW2 (a bit of hyperbole, and doesn't account for secret allies collaboration), rather than have the country destroyed. Having a nuclear deterrence would mean not having to surrender again, when the Russian comes.

Hopefully NATO membership has the deterrence without the drawback. But of course NATO wouldn't be NATO without its nuclear members. And with the US becoming unreliable, Sweden's defence is still backed by the nuclear agreement with France. So own nukes or not, at least by treaty Sweden still has nuclear weapons as deterrence. Is it really vital to discuss the operational control? If that's the sticking point, then fair enough. I'm not saying it's NOT a difference.

A better critique of Sweden is its relatively huge arms exports. But that too is not black and white. Si vis pacem, para bellum (if you want peace, prepare for war).

> The environmental argument

Which is an economic argument, too. It's merely not been priced in yet.

Yup. I guess we still disagree if nuclear is needed long term for Dunkelflaute, and for countries with darker winters.

It's one thing to use storage for overnight. Another if it's for a couple of weeks. And yet another for 6 months.

And take Sweden: Lots of hydro power yes, but where it can feasibly & economically be built, it already has. You can't expand it. And that's not even mentioning that all you need is a drought in winter, and you can no longer rely on it. Currently Sweden is backed by coal plants in Germany. But we need to plan for it being Dunkelflaute in Germany and Italy, at least enough to not have surplus for the nordics.

As for "it's always sunny somewhere", sure, but you need to get it there, somehow. Transmission is why electricity prices in Sweden can be "more than infinity percent" more expensive in south of Sweden compared to north. (electricity prices in the north has gone as far as negative), and is why data centers are built near power plants, or at least it's part of DC location planning.

If transmission costs were negligible then we wouldn't need to take power into account for DC placement. I have some rants about this related to how some DCs are away from population centers to save money on power, noticeably sacrificing latency to the actual end users.

We should do what we do for fossil fuels: Permanent storage in the atmosphere.

> No nuclear power plant pays the true insurance cost.

Do fossil fuel plants pay co2 costs, or insurance costs for killing the planet? Well, it wouldn't make any sense, since it's not accidents that kill in that case, but the steady state.

The radiation from coal power alone (excluding accidents) kills more people every single year than nuclear power has killed in its entire existence (even including accidents).

In my opinion the best argument for nuclear power is not money, but environmental.

The radiation from coal power alone (excluding accidents) kills more people every single year than nuclear power has killed in its entire existence (even including accidents).

But also: What is the cost of non-nuclear's raising of co2 levels and climate change?

Interesting take to trivialize oil spills.

Take coal, then. The radiation from coal power alone (excluding accidents) kills more people every single year than nuclear power has killed in its entire existence (even including accidents).

But you focus on one single thing: Oil spills. The grandparent comment talks of fossile fuels. What about co2?

Co2 has been leaking out into the atmosphere for many years. You know what happens to it? It stays around basically forever, kills enormously (directly and indirectly), and in fact causes a spiralling effect.

Sweden has been phasing out nuclear for 40 years, after a referendum where the people had the choice of "No nuclear!", "No nuclear", and "No nuclear". There was no "yes".

It's been phasing out nuclear since then.

Nowadays the Green party and the (formerly named) Communist party are the only ones against nuclear power, but thanks to the left block winning the recent election, they may push that one issue enough that they get to continue the destruction of our planet.

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

It's been done.

Oh that's cool!

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.

Looks like speeds have picked up since I last looked at this, when a signature in TPM took 0.7s and no concurrent capacity.

https://blog.habets.se/2012/02/Benchmarking-TPM-backed-SSL.h...

https://blog.habets.se/2012/02/TPM-backed-SSL.html

Well, it's been over 14 years so I should hope so.

> 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.

Comes with the territory, no?

"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.

What would you say would set ABBA apart, here?

Sure. Hence my Netherlands example.

Not quite what I said.

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.

Yes, it's called a hypothetical.

> 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.

As a Swede in London, it's annoying that IKEA staff don't understand you when you pronounce the names correctly.

You have to change letters (e.g. å is not a with an accent. It's a different letter) and read it like you don't know the language.

> 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.

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.

Which is why the software world is full of technical debt and frustrating buggy software.

But I agree that it's must faster to get the wrong answer than the right one.

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.

Yup. I don't have to like GC to name a benefit of it. Which is good, because I don't like GC.

Java is a particularly good example of GC being bad[1], but I've also found it to be a tech debt generator in Go.

[1] A rant, which touches on GC stuff: https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experim...

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.

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.

I was explicitly talking about exactly one very specific part a way to implement GC.

It was very clear that I was not talking about the active parts of the garbage collection.

It's really cheap to produce garbage.

> 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-...

And once again this old blog post of mine comes to mind: https://blog.habets.se/2020/12/Bypassing-safety-check-for-ob...

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.

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.