reitzensteinm

M:N distribution itself has been massively devalued in Space Age - it’s so cheap and easy to build everything from scratch in situ with the new production buildings.

Eg you don’t need city blocks making circuits, just pipe in molten metal and make them with foundries and EM plants. And then you also get steel, copper wire, gears, whatever else you might need.

There are a few exceptions of course, like lubricant for electric engines, but it’s not nearly as complicated as it was pre Space Age.

Washing ore is probably the easiest solution - research high levels of mining productivity, put quality modules in drills, filter off uncommon+, and loop them through recyclers until they are at the desired quality level.

It’s inefficient but has a very low cognitive load.

You can improve the efficiency a little by increasing the quality floor each level, eg rare iron ore, epic iron plate, legendary steel. But in my post endgame playthrough I was drowning in so much legendary ore with this method I didn’t bother.

I agree they’ll be viable. They’re much harder to use but roughly equally good.

Also my late game experience is probably not representative of the phase just after victory where trains may have a slight edge - there could be a sweet spot there where the decoupling is worth it because you can horizontally scale through bottlenecks.

By the end I was using dedicated patches for each science so trains just get in the way.

Yes. Quality boosts storage for wagons and speed for trains. Also unloading is more compact due to inserter belt side selection.

I did a 1m eSPM base though, and I don’t think the totality of all of that would bring me back to trains. Belts are extremely reliable, and I have never managed to make trains so.

If anything, in immature engineering organizations, preserving netcode invariants to successfully deliver a multiplayer project might benefit from a little of that disposition.

My belated apologies for the misunderstanding. The irony of me coming here and throwing shade on your work as a result is not lost on me.

I never doubted that. It’s clear the author knows their shit.

“Functions use dynamic scoping. This is categorically a mistake, and one which ironically has been suggested to seriously mess up fexprs.” (links to Kernel)

It’s possible my interpretation wasn’t correct and the author was citing Kernel’s approach as sanity. That would make sense technically.

The dig at Kernel is kind of depressing. It's probably an evolutionary dead end, but god damn it, the world is better when people try things. Dismissing them doesn't make you cool.

I had Windows and Mac laptops back then, and the HN snobbishness around the superiority of the Mac was genuinely baffling.

My i9 2019 MBP with discrete graphics was probably the worst laptop purchase I ever made. Docking it to an external monitor would enable the GPU, so even when idling it would run the fans and drain the battery.

I’d read cautionary tales about Windows laptops being pulled out of backpacks scorching hot as they failed to shut down. But that happened to my Mac all the time, too.

The M series though is incredible. I can’t imagine buying a Windows laptop now.

Are we reading the same post? They literally point to bugs X and Y.

I don't see politics, I see frustrated maintainers of a hobby project that aren't particularly professional.

Bun in its current state absolutely has issues like segfaults. As nice as it is, I moved off of it back to node for production.

Folks generally tolerate issues if they believe they’ll get better with time. I know I did for a while. If that confidence collapses, that’s not politics.

Well, I found the proposal clear and your response confusing.

There are reasons it might not work, not least of all political. But a link to a paper picking a bone with LCoE is talking past GP.

No Code, surely?

From my experience, a tiny alarm sounds, a voice says cyclist approaching and the door clicks to locked. At least I believe it did, I heard a sound. I didn't check the handle.

I don't believe the car was specifically in a bike lane at this time but I'm new to the city and may have missed the markings.

Elektrek went from insufferably pro Tesla to insufferably anti Tesla. If you liked it before and not now, your quarrel is with the direction of the propaganda.

I wrote a library called Temper, which simulates the Rust/C++ memory model with atomics in a similar way to Loom. But it goes much deeper on that narrow domain, and to my knowledge it's the most accurate library of its kind with the largest set of test cases.

If you simulate using mock CPU instructions like memfence or LL/CS there's no guarantee your model fits your ultimately executed program.

Unless of course, you do something like antithesis and directly test what compiled. It's an interesting alternative world.

I've taken the liberty of adding you to LinkedIn - would love to grab a drink next time you're in the SF Bay area.

https://github.com/reitzensteinm/temper

At the intersection of these two topics, does Antithesis have any capabilities around simulating memory ordering to validate lock free algorithms?

You can still rewind by storing checkpoints, resuming at the most recent before the seek time and fast forwarding from there.

The updates thing is a shame. You can store multiple configuration files for balance patches, but executable code is much harder.

There's not a lot of churn in Unity, but that's more because they mostly fail to ship anything of significance than due to excellence in backwards compatibility.

I was in the audience when DOTS was announced, and a decade later Cities Skylines II showed how ill equipped for prime time it remains (not that the developers were blameless).

Yes, absolutely. I did that before vibecoding too, as rapidly editing and testing is so crucial.

The way Bevy's internal state is so easily saved and loaded is convenient for this.

Compile times are my biggest struggle, too. I'm vibecoding Bevy with parallel agents, and the bottleneck is often compiling the changes on my 7950X, not getting Codex to write them.

As far as file sizes go, I'd be really interested in how a Rust compiler that didn't monomorphize so much would perform. Right now you have to modify the source code to write polymorphic generic functions, but it doesn't strictly have to be that way (at least as far as I can see).

I wouldn't use Bevy for a web only game either, especially while it's still single threaded on WASM.

This site is excellent. I emailed the author to thank them after reading it cover to cover, and they replied and asked if anything was unclear or if there was anything I wanted to see explored more.

Quite the dedication to a free resource!

But this document does not. Note it says 12.5%, not 12,5%.

1 TWh on the scale of a country is very little - a 1 GW nuclear plant operating continuously would generate over 8 TWh a year.

Nevertheless the back of the napkin math of land requirements for solar check out, so it was probably just a typo and OP meant to say PWh.

Ember is an absolute treasure. Often you'll see articles on HN from places like Elektrek which are blogspam linking back to Ember's original reporting.

Their electricity data explorer is to my knowledge the most complete on the open internet.

Could you macroexpand your claims a little here?

"An example of the unaddressed complexity: use of acquire-release semantics for head_ and tail_ atomics imposes no ordering whatsoever between observations of head_ and tail_."

The Acquire / Release in version 4 looks right to me, but I'd like to know if I'm missing something.

Also, while your linked paper is good background for what the C++11 memory model is intended to abstract over, it's almost entirely its own thing with a mountain of complexity.

Somebody else in this comment section brought atomics knowledge to an Acquire/Release fight and it didn't go well.

As a starting introduction I'd probably recommend this:

https://www.amazon.com.au/C-Concurrency-Action-Practical-Mul...

How did you test with 1024 players - were they real? Often synthetic loads are very different to those caused by real players.

I owned an i9 MBP with a discrete GPU. It absolutely was too thin. The CPU and GPU ran hot, it throttled like crazy. It would drain battery while USB-C docked while idling. Worst laptop I've ever owned.

The M1 Max I replaced it with was the opposite. I don't think I heard the fans for the first month. But it was much larger.

Based on the fanless Air, I strongly suspect an M1 Max in the old chassis would have been totally fine for non synthetic workloads and an M1 Pro would probably have been fine in all scenarios.

But I think they over corrected on the chassis design when they were shipping borderline faulty products and haven't walked it back yet.

It's all about relative difficulty. It's not trivial to convince LLM vendors to include your pet new language in their internal synthetic datasets, and you can build your own and publish it but it'll be fiddly and expensive.

But compared to the immense amount of effort that goes into convincing a critical mass of humans to learn and write about your new language, and using _that_ material to train an LLM, I think it's fair to say things have gotten easier, not harder.

Coding is a verifiable domain, so I think you actually have it backwards on that first point. We can now synthesize Stack Overflow sized datasets for an arbitrary new language, and use those to train LLMs to understand it.

It's expensive of course, but if a new language is genuinely better for LLMs to write and understand, that would not be an issue.