I think this is actually the reason the Neo has 8 GB of RAM (non-upgradable). It’s their anti-cannibalization strategy.

They’re relying on the huge portion of their existing laptop market who self-identifies as “tech-savvy” or “enthusiast” and thinks 8 GB of RAM is a non-starter.

Those folks will keep buying Mac laptops at double (or triple, quadruple, …) the price.

> I think this is actually the reason the Neo has 8 GB of RAM (non-upgradable). It’s their anti-cannibalization strategy.

It has 8 GB of RAM because they wouldn’t be able to hit the price point of $599 with more; their target audience doesn't need more. It's also why the SSD is slower than a MacBook Pro or MacBook Air; it's the only device in the lineup other than the entry-level iPad with a sRGB display; the other devices have P3 Wide Color Displays. No Thunderbolt ports, only supports 1 external display and only at 4K. No Wi-Fi 7.

These are some of the compromises they made to keep the price down. They're also using a binned A18 Pro with 5 GPU cores instead of the 6 core version in the iPhone 16 Pro and Pro Max.

There are lots of potential customer for which a Mac laptop was out of reach; it's a lot more affordable at $49.91 /month for 12 months for the $599 model.

Its display is better than PC laptops in the same price range, but that display is a non-starter for graphic designers, video editors, etc.

That's why cannibalization is a non-issue.

That presumes that “killer AI drones” are a valid way to accomplish some valid goal.

For example, I do in fact want to live in a world where only the bad guys have child soldiers, use human shields, deliberately target civilians, and abuse prisoners of war.

If the other guys have child soldiers, you don't need child soldiers of your own to defeat them.

If the other guys have an army of killer robots and you don't, you are going to die.

Do not succumb to "we have to win the race" reasoning and escalation, when the race is leading off a cliff. It is, in fact, possible to stop things via international cooperation. Treat it the way we do nuclear proliferation. (Efforts to stop nuclear proliferation have not been perfect, but they've been incredibly effective and made it much more difficult to make the problem worse than it already is.)

Nukes are intrinsically complex and require a high degree of skill, time, and resources to pull off.

Attack drones can be as easy as strapping an off the shelf grenade to an off the shelf drone.

> TypeScript also was specifically designed so engine could strip types and execute result code.

That's no less a build step than concating, bundling, minifying, etc. When people say "I'm against processing code before deploying it to a web site" but then also say "TypeScript is okay though" or "JSX is okay though," all they're really saying is "I like some build steps but not others." Which is fine! Just say that!

If you have proof of home ownership and proof of legal guardianship of the child, what’s the problem?

I can see it being a problem if e.g. a bunch of family members are putting their kids in a school district based on a single home owned by a grandparent. But if that grandparent was also the kid’s legal guardian, fair enough!

> It’s also very brittle and one charismatic populist away from unraveling

All sufficiently large governments (really all organizations of any kind) are necessarily like this, from the most successful attempts at open societies to the most autocratic. They all require constant vigilance both to perform their intended function and to preserve themselves into the future.

Note that even though the U.S. has a Constitution, the entire U.S. government is still, like the UK, highly reliant on inexplicit norms many of which go back hundreds of years before the U.S. was founded. They’re both still English common law systems.

That generally works for timestamps (Temporal Instant). But it doesn’t work for representing calendar dates with no time information (Temporal PlainDate) unless you add an additional strict convention like “calendar dates are always represented as midnight UTC”).

That’s uglier because, if you were previously doing new Date(), you almost certainly don’t want a zonedDateTime. You almost certainly want an Instant.

Good luck making sure no one ever uses a “yyyy-mm-dd” string to represent a calendar date in a JSON API, then passes the value to the Date constructor, then formats that Date in a browser. It’s an extremely easy mistake to make without very strict conventions around how calendar dates and timestamps are represented across the entire stack.

This is the most common way this happens in my experience - people naively assume that by giving just a date and not a time surely it wont do timezone conversion, but it does (and even worse that behaviour is not at all consistent between different languages/systems). Oh and fun fact JS parses 'YYYY/MM/DD' (slashes instead of dashes) differently from the dashed format as well...

The 'safe' way that I try to make everyone use for 'wall clock'/'business' dates is 'YYYY-MM-DDT00:00:00' (without the Z) - this unambiguously parses as 'this date in the current timezone' in basically every languages Date type and it's ISO 8601 compliant. However it's still a pain in the ass to keep straight when serializing as the 'default' output is usually a timezone converted UTC string (Z at the end).

This is also true of JavaScript Date instances, so I’m curious what solution you had that did work with raw JSON stringify and parse.