WorldMaker

Something that stood out in skimming the document was how close to parity the two languages seem to have in general, especially with things like Span<T> filling in a lot of the things that might have been "gaps" earlier in C# history. Knowing Microsoft's historic biases and wars, a part of me is wondering if this document is something of a trojan horse for the opposite conversation, trying to sell more Rust users that C# can be a "system's language" today when a Rust mindset is brought to it.

Especially the "unfair" comparison of the document sticking as much to the BCL as possible and trying to avoid NuGet packages, but needing cargo packages for a lot of the side-by-sides, seems to favor C# for some types of programming.

It's great that C/C++ developers are finally starting to see the light and moving to Rust. Maybe Rust is finally the bridge from C/C++ to C# that Microsoft has historically been missing and has been the source of some internal wars at Microsoft.

Keeping a UTC offset is two extra bytes and with a UTC offset you can do all of your time comparisons and time math as if everything was in UTC, but you have extra debugging information in the UTC offset. It's still sometimes useful to store a time zone as offsets to timezones certainly are not 1:1 (esp. with DST math), but some places like logs and past dates UTC offset is sufficient and you don't even need to store timezone.

Postgres doesn't a native type that supports UTC offsets, but some other databases do and it is extremely useful. At this point in my career, I would never choose UTC storage over UTC Offset storage.

SQL Server has `datetimeoffset` which stores the UTC offset (and so roundtrips it), which is definitely an improvement. (You still may need/want a string timezone column even with UTC offsets, but you don't need a denormalized _utc column because datetimeoffset math just works as if the times were all UTC.) It seems like something that Postgres could use. Especially because the overhead for storing UTC offsets isn't that much. (10 bytes versus 8.)

I've seen too many ways storing everything as UTC goes wrong/gets confusing. Round-tripping at least UTC offset (which unfortunately Postgres `timestamptz` in this case does not do and is effectively the same as storing as UTC) gives you more debugging tools for events in the past and more opportunities to do the right thing for future events in worst cases (strange, unexpected DST shifts). The best option is if you can also round trip exact time zones such as IANA strings like "America/Los_Angeles". Even fewer databases support that natively right now (as a single optimized column).

When UTC offsets roundtrip you can do all your date math as if everything was in UTC, but still not lose information from the user about what time they thought an event occurred at or might next occur at.

A lot of the design reads like almost but not quite ActivityPub.

I've known people advocating for proportional fonts for source code for a long time (many of them also in the literate programming camp). It would be funny if LLM slop was the final aesthetic push over the last few hurdles there to making it more common.

The other difference was that Bootstrap met WCAG standards and had a very strong baseline of accessibility. These LLM slop outputs meet no such standards and seem to laugh in the face of accessibility.

The vast majority of LLM slop seems to be Tailwind to me, so sort of the opposite of a library, just a bunch of common patterns in Tailwind so common as to be everywhere but not common enough anyone bothered to put them into a reusable library.

Exactly. The benefit to the Bootstrap boom was it elevated a lot of cookie cutter designs like a raft on a series of sensible defaults that were are close to sensible/good taste as some very talented designers could make industrial cookie cutter standards. Bootstrap enshrined smart, intelligent defaults like good color contrast and a baseline of accessibility for developers just copy and pasting and modifying what Bootstrap gave them. For a brief moment the "I just need to get this done" web had a good accessible baseline.

LLMs aren't starting from sensible defaults and don't have to meet WCAG scores unless you tell them to (and even then might hallucinate checks they didn't actually make).

All caps text is a roadblock for reading speed/comprehension. Accessibility experts were finally convincing major company design standards to stop doing it when LLMs made it a default again [0] for headers and incidental text.

Not to mention that all caps text is also generally associated with shouting and just feels rude to some readers.

[0] Or more accurately trained on all the bad examples before experts started catching them and has stuck to the mistake.

It's partly a "Don't think of a Pink Elephant" problem. I've worked on several projects where I had to keep telling prompt writers to stop writing negative examples because the more you include the more its "attention" to them is all it has. Like telling a toddler not to do something and being surprised that is now all they can think about and they want to keep doing it. These prompt writers kept getting surprised that I'd delete all their negative examples and harshly worded "Don't do X" and "Never Y" and "NO: Z" sections they spend so much time on and got better results with smaller more focused positive example only prompts.

I've seen a couple companies already change their design standards to "best in class Tailwind designs from Claude, use this prompt file/Agent file/skill file combo for all UX work".

Looking at automated emails I get from Microsoft and GitHub it certainly feels like they are one weird layoff from doing it company-wide.

The worst part is these glassification Tailwind heavy slop almost universally fail WCAG guidelines (and personally, seem hard to read to me because of taking the whispy sans serif thing to its foregone conclusion by almost exclusively using what to me are unreadably thin weights of the already too thin Inter font). The slop is going so quickly backwards for companies that invested in accessibility and these companies need to be taken to task for forgetting design isn't just aesthetics but readability and accessibility.

"Confidence scores" have always implied an anthopocentric meaning that doesn't exist. An algorithm doesn't have "confidence" in the way that a person has confidence, but as soon you put something with that name in front of a business person they assume the number is always a meaningful "letter grade curve" or "universal percentage". I still believe so much that the old quote to "there's lies, damned lies, and then statistics" remains a key to understanding so much why ML is leading to dumb outcomes versus hype. People don't understand statistics, so machines that produce nothing but statistics especially confuse people. (I feel this applies to LLMs as well.)

LVT is about assessing improvements, conservation can be understood as an improvement and valued as such. For the same reasons that urban parks should have a different tax assessment than low value surface parking lots.

I don't know how hard it is to imagine the easily elided phrase "garage or parking lot or street parking or whatever parking situation" after apartment, but unless you also park in your apartment on the 6th floor it seems silly to ask this question to me.

> Using a functional language for data transforms sounds like a sane idea, haven't played around with it yet but it's definitely on my list now.

It's been one of the plays that the F# community has also been trying to make (somewhat with a modicum of help from Microsoft's marketing arm, but not enough help from what I've seen) pitching F# as a language close enough to Python to feel familiar and useful to data science but with the performance help of rich ML types and the modern .NET performance ecosystem.

(To my experience: getting "fast" compared to Python seems easy for most functional languages. Getting data science out of Python seems hard for a lot of sociology reasons more than technical ones.)

Interesting, most functional languages are quite terse and heavily whitespace, so you would expect raw token counts like that to be lower simply because source documents are on average shorter. Even having to make up for disadvantage things like C++ style operators like &&= all having single tokens from heavy use across a variety of languages but fancy functional operators like <=> being much more rare and in worst cases of undertrained models needing multiple tokens to express.

But yes, terser source documents and low raw token counts could mean lower prediction rates and more prediction attempts needed to get intended results (again, especially if the model was undertrained in that particular language).

EV batteries are reliable. "Range Degradation" is mostly a disproven myth. [0] Range figures vary with driving style, but that's the exact same issue with gas range, gas cars just had very bad/loose/nonexistent feedback on driving style inefficiency.

[0] Outside of the non-temperature controlled batteries of "classic" Nissan Leaf models and early Tesla models, but even then "range degradation" is largely overstated and statistically very few batteries were ever replaced in the lifetime of those cars.

No, I've been pretty consistent that I don't agree there's as much friction as people think there is, that in our society right now are a bunch of sociopolitical issues driving people away from doing the real research or actually trying to live with an EV. If goalposts seem to be moving it may be because you can't firm up your point on what "friction" even means to you.

But electricity is not nonexistent. It's easier to run an EV in rural Ohio than a gas car because you can install a real nice charger in that huge garage you have or outside your big barn next to your gravel lot, whatever, you've got space and a grid connection. That's not currently the average mentality, but that returns us to the sociopolitics of rural Ohio and EV adoption in the US in general more than any of the technicalities.

> since there are gas stations all over

That's the assumption, though. There aren't. There is an illusion of it, sure. I gave that anecdata from personal experience. It isn't "ridiculous", it's called having lived (and learned to drive) in rural Ohio.

> The cost differential is enormous and completely changes the economics of cost per mile.

Which is exactly the point and why it is a bonus. You can't do that with a gas car effectively or cheaply. You won't pay someone to come and install a gas service in your home or apartment with the express reason for fueling your car. That you can with an EV and would get a game changing efficiency and cost reduction is an incredible bonus.

> Sure, but a full gas tank gets you further than a full battery.

That seems to be less of a factor today. Most batteries have hit the same or more range as comparable gas vehicles.

Some EV models already have ~600 mile range which is double their gas counterparts.

> We have friends with a long range Tesla that takes them days to charge on 120.

Sure, but that's to 100%. You can drive a car with less than 100% battery. A 120v charge can add as much as 40-60 miles range overnight. That's an average person's regular commute. The car might "never" be at 100% if the 120v charge is all it ever gets, but for some people they might never need a fast charge in an average week or even month.

Take all of that anecdata and replace a gas car and it is the exact same with the same mental load: I've been on 18% fuel tank and wondering if my car will actually make it home or stall out on the road. I've been about to go somewhere and realized my car isn't fueled and and called a taxi or a Lyft as faster than the detour to refuel my car.

"It's an unreliable transport without having a gas pump at home." That just sounds silly. Funnily enough that was exactly one of the early complaints of gas cars when electric cars were preferred in the very early days of cars. It was a complaint when gas pumps were rare and hard to find, or didn't exist at all yet and you were pulling gas canisters from the back of a pharmacy.

It's a more reliable transport than a gas car because I can charge at home. (I can't do that at all with gas.) It's a more reliable transport than a gas car because in a pinch I can find an outlet on the outside of my hotel and trickle charge enough to get me to the next charger. (When was the last time a hotel had canisters of gas just in case?) It's a more reliable transport than a gas car because I can find RV plugs in national parks and state parks and campgrounds far away from chargers and gas stations. (You ever see what you might get charged for a tow from a remote national park, even if that tow is just dropping off a canister of gas?)

The impression of the charger situation being more inconvenient than gas stations is already flipping and has room to flip a lot more, possibly surprisingly quickly, as gas prices rise and low margin gas pumps go out of business.

I thought Return to Monkey Island did a very good job with it, and it was indeed exactly what MI2 was trying to say and what MI1 even foreshadowed, just refined with the time away from the project. It answered "What was Ron trying to say in the MI3 he wanted to write?" and it ended up doing it without diminishing Curse, Tales, or even Escape, and somewhat including them in the fun. (More Curse and Tales than Escape, it certainly ignored/retconned Escape events, but Escape's appeal has always been smaller.)

The Remaster added modern controls and even a point-and-click mode. Worth revisiting.

It's not a bad faith argument, it is comparing like for like. (Saying that it isn't like for like seems to me to be the more bad faith argument in 2026.) If I have a gas car with 300 miles of range I go about 297 miles safely between fill ups. If I have an EV car with 300 miles of range I can go about 297 miles safely between charges. Those are the same characteristics.

The part that isn't like for like sure is that there is an increased friction that even a "fast charger" can take a magnitude more time than a gas pump. But fast chargers are much safer and can be parallel tasked (running other errands while a charge happens) whereas gas is an explosive and requires diligent observation while refueling (despite how many people seem oblivious to all the warnings not to leave a refueling car unobserved and a long history of explosion statistics).

In my experience, fast charging time and lack of home charging ability (and under-estimation of Level 1/2 charging utility) feel like red herrings rather than actual issues. These things get talked about a lot, but the real world experience of them isn't the friction people believe it is. The biggest issues seem to be far more sociopolitical than technical to me. People have invested too much of their identities in gas. Entire political parties seem devoted to propping up gas sales for as long as possible.

It's true in the US market. Europe and Asia are seeing a flood of smaller EV cars from Dacia, Renault, BYD, VW, Fiat and far more. The US is getting left behind.

You don't need a home charger to enjoy driving an EV. A home charger is a bonus to driving an EV. Do you know anyone who has ever had a "home gas pump"?

Not to mention how many people sleep on Level 1 and Level 2 charging, which are cheap or cheap as free in many homes. (Garages have had electric outlets for a long time. Some have had "dryer plugs" for nearly as long, due to power tools one might own.) Trickle charging doesn't get you to 100% overnight, but no one drives on a 100% full gas tank every morning either.

I wish they had a variant in a more normal sedan or hatchback than its "PT Cruiser thing", but it is still one of the closest in the US market to a normal car.

It's too bad Europe and Asia get all of the nice EV sedans like Dacia Spring and BYD Dolphin. This article even says Toyota hasn't committed to this Corolla EV in the US market, which is shameful.

Again, I still don't need to know how `i` is getting invoked if my security bar is `no import() calls`. `i`'s declaration is the red flag. Full stop.

Notably `import` is still a special reserved word in JS, so it does not exist on globalThis. `import()` in function usage is special and so to get added to globalThis has to be redeclared in a wrapper function such as `i`. That redeclaration is now always a red flag. I can work to reverse engineer whatever is calling it, or I can simply declare that entire ESM dependency untrustworthy and move on to something more reliable.

(ETA: Especially because in an ESM context, to be declared on globalThis it cannot use simply top level `var`, it also has to especially be globalThis object pollution, which no matter how you access globalThis to pollute it, looks weird and strange. Bonus: If the source is Typescript it will also likely involve an explicit `as any`, another potentially untrustworthy marker in a downstream dependency.)