kji

This is misleading; a better analogy would be if someone swapped out all iPhones in the store with fake ones.

You cannot get an eSIM for a Chinese phone number as a tourist; this is a restriction set by the Chinese government.

> the third party, unaffiliated, developer experience is better on an EVM than it is is on a traditional centralized database.

This is definitely a take, given how easy it is to write a program with security bugs using Solidity due to specific concerns like reentrancy that only exist due to the unique way smart contracts work. The inability to "undo" a fraudulent or mistaken transaction without requiring all validators to fork the chain also makes this a non-starter for many developers.

> your users pay to update the state of your application

Also a weird thing to call a "feature" for developers when this actively drives away potential users.

Would love it if the scrollbar was draggable on iOS! I thought it was broken until I realized you can click on a spot to scroll to.

The instructions state the following:

> Imagine you begin a journey in Seattle WA, facing exactly due east. Then start traveling forward, in a straight line along the Earth’s surface.

Where does it say to "travel exactly due East"?

Perhaps the HN headline doesn't match the article, but the instructions say:

> Imagine you begin a journey in Seattle WA, facing exactly due east. Then start traveling forward, in a straight line along the Earth’s surface.

where there isn't any wording saying "go east in a straight line".

I don’t think this is a fair conclusion; web development is harder than desktop GUI development for various reasons.

For one, clients (mobile, desktop) are drastically different with all sorts of downstream implications:

- Differing screen size requiring responsive design

- Internet speeds magnitudes different

- Intermittent internet

- Uneven feature support due to different versions of browsers

- Everything needs to be JS at the end of the day

Desktop apps generally don’t have to worry about any of these issues.

Also, desktop GUI frameworks are typically either fragmented (one per OS) or don’t look OS-native.

HSTS is intended for browsers. For API clients the correct behavior (following curl's lead) is probably to never follow/make any redirects by default.

Aren't these two forms isomorphic:

    type MyUnion = { type: "foo"; foo: string } | { type: "bar"; bar: string };

vs

    type MyUnion = Foo of { foo: string } | Bar of { bar: string };

You still need some runtime encoding of which branch of the union your data is; otherwise, your code could not pick a branch at runtime.

There's a slight overhead to the TypeScript version (which uses strings instead of an int to represent the branch) but it allows discriminated unions to work without having to introduce them as a new data type into JavaScript. And if you really wanted to, you could use a literal int as the `type` field instead.

The AgeMin/AgeMax example seems more of a deficiency due to a lack of named function parameters; it would be equally clear if it had a type signature (using OCaml as an example) of

    val is_admissible : min_age:int -> max_age:int -> bool

Both Katran[1] by Facebook and Unimog[2] by Cloudflare are L4 load balancers written using XDP. It's factually incorrect to claim that XDP is useless on servers as many companies intentionally choose to design their systems around commodity hardware.

  [1]: https://engineering.fb.com/2018/05/22/open-source/open-sourcing-katran-a-scalable-network-load-balancer/
  [2]: https://blog.cloudflare.com/unimog-cloudflares-edge-load-balancer