esprehn

GKE uses spanner (with an etcd API layer) per the docs.

https://docs.cloud.google.com/kubernetes-engine/docs/concept...

https://cloud.google.com/blog/products/containers-kubernetes...

GitHub and LinkedIn both appear to be pretty successful businesses.

Is Xbox really worse than Play-Station?

It's a pretty good name actually because it's unique, easy to Google, and is never ambiguous in conversation. It's all the suffixes that made a mess of it.

Yahoo. They very nearly bought Google too, but refused the initial $1m offer and then bid too low the second time. Kind of hilarious to see how that played out over time.

  Yahoo had two failed attempts to acquire Google; in 1998, Larry Page and Sergey Brin approached Yahoo to sell their nascent search engine for $1 million, but Yahoo declined the offer.[37][38]

  In 2002, when Terry Semel entered into negotiations to purchase Google. Google was reportedly seeking a price of $5 billion. After weeks of negotiation, Yahoo's final offer was $3 billion, a figure that Google's leadership rejected, leading them to terminate the deal.

The good part about a language runtime is there's a massive corpus of tests that are in that language and agnostic to the implementation language.

For a JS engine that's Test 262: https://github.com/tc39/test262

For node that's its unit tests which are mostly JS: https://github.com/nodejs/node/tree/main/test

Node also runs the web platform tests too: https://web-platform-tests.org/

Bun has a similar large corpus of JS/TS tests: https://github.com/oven-sh/bun/tree/main/test

You're right about general purpose rewrites, but language runtimes are a lot easier.

Apple was doing effectively everything on that list, though the self driving car was cancelled and the AI is now gemini.

Is the simpler thing not Lambda/Cloud Run (with terraform)?

On the application developer side k8s is awesome fo, but the you look inside the box and it melts your face off.

I'm not sure a middle ground exists unfortunately. It's either full service like Lambda or bag of knives like k8s.

I assume they meant the Attention process in LLMs, not the human concept of paying attention:

https://en.wikipedia.org/wiki/Attention_(machine_learning)

One big difference seems to be Mastra has tests and this project doesn't.

It also can't inherit css variables which is unfortunate since it means the image doesn't respect the theme.

They totally could sanitize it, just like they did with the gadget proxy, they just choose not to fix this ancient request.

It's like my ticket to add data url support to sheets. It just gets punted year after year.

There's a whole movie about a snail that's super fast (Turbo). An adult version of that isn't so far fetched.

Yes, I was around during the original discussions. AbortSignal exists because TC39 was taking too long and cancelling fetch() is table stakes for a networking oriented platform like the web.

Those threads are a good example of what's wrong in TC39. A simple AbortSignal could have been added, but by the time it's reconciled with SES, large speculative APIs like Governers, or the original attempt to add a parallel throw mechanism just for cancellation, nothing actually gets done.

It's been 10 years since CancelToken was first discussed and we're still debating it.

I just can't help but imagine those long lived rats escaping and taking over our cities. We already struggle with the rat population and they only live 3 years, imagine if they lived 15.

Also I love rats and totally agree they're tough pets because they don't live long enough. We had many of them growing up and spent a fortune removing tumors.

AbortSignal is same thing on the Web. It's unfortunate TC39 failed to ever bring a CancelToken to the language to standardize the pattern outside browsers.

The proposal already exists [1], but vendors would need to agree to both prioritize and ship it.

Right now Chrome is much more focused on AI related APIs (sigh) and not stuff like FontMetrics.

[1] https://drafts.css-houdini.org/font-metrics-api-1/

The FontMetrics API solves this, hopefully browsers will ship it someday.

https://drafts.css-houdini.org/font-metrics-api-1/

RIP eae@.

It can request with a JS call. It can't passively collect it without you approving first. The article is written like calling that JS function will turn on location tracking without consent.

This is very cool, but I'm confused why the React player is smaller than the HTML player. What's actually in the size comparison there?

The worker situation would be much better with inline workers (or modules).

https://github.com/tc39/proposal-module-declarations

Unfortunately the JS standards folks have refused so far to make this situation better.

Ex. it should just be `new Worker(module { ... })`.

No one really does, but there's one particular individual who keeps pushing to support things like node 0.3 and who also maintains all those low level intrinsic packages.

2022. I'm not sure phones recorded useful video in 2002.

Ah this is what I missed: https://daringfireball.net/linked/2026/03/12/macbook-neo-on-...

It's not just the menu bar icon (which can definitely be spoofed), but an on screen dot where the system is controlling pixels directly bypassing any OS level drawing on the screen.

Related: https://www.reddit.com/r/iphone/comments/1in0681/iphone_16_m...

The missing camera light seems pretty serious. Any sandbox escape can turn on the camera and record without you noticing. Or your school or employer could. If you're in full screen mode the menu bar is hidden too. It's a very strange move for privacy centered Apple.

The web doesn't work without dynamic feature detection. I couldn't find anything in the component model about how this is expected to work.

The DOM is not a static interface, it changes both across browsers based on implemention status and also based on features enabled on a per page load basis.

The multi browser ecosystem also mainly works because of polyfills.

It's not clear how to polyfill random methods on a WIT interface or how to detect at runtime which methods exist.

OTOH the JS bridge layer we use today means you can load JS side polyfills and get wasm that's portable across browsers with no modifications. There's more to the ecosystem than just performance.

Those verbs (reduced, decreased, increased) all assume the situation was "bad" already. Avoiding that in the initial design is what's poorly rewarded.

Building a system that's fast on day one will not usually be rewarded as well as building a slow system and making it 80% faster.

Have you used a MacBook as a daily driver since the M chips came out?

This is really cool, but I wish it was sorted by date. It's difficult to see the narrative since it jumps around.

Web Streams do feel rather painful compared to other languages. The author ends up basically describing kotlin flows which are great and I wish the web would adopt that model (Observables wanted to be that but the API is much worse than flows in practice).

Fwiw the original Streams API could have been simpler even without async iterators.

  interface Stream<T> {
    // Return false from the callback to stop early.
    // Result is if the stream was completed.
    forEach(callback: (chunk: T) => Promise<boolean | undefined>): Promise<boolean>
  }

If we're optimizing allocations we can also avoid all the {done,value} records and return a semaphore value for the end in the proposed API.

(Web) API design is really difficult and without a voice in the room pushing really hard on ergonomics and simplicity it's easy to solve all the use cases but end up with lots of awkward corners and costs later.

Async call stacks is an optional feature when the devtools is open. There shouldn't be overhead from await like that?