macguillicuddy

Interesting! Looks like a race condition (with a 1ms window) during squawk allocation (the process that gives each aircraft a 4 digit identifier for ATC purposes) caused data corruption. They present that window as being small but 1ms is a decent chunk of time in our work lol

I agree that devices should work independently. But I believe the fundamental baseline should be open interoperability. Yes, the dishwasher should allow a delayed start from the machine itself. But it should also have secure yet open interoperability so other authorised systems that care about the dishwasher can interact with it. I think there's ultimately a user experience benefit. I'm familiar with my phone, its UI paradigms etc. If I (or my gran) can use the dishwasher through an interface or voice assistant we're already familiar with then that's a win. Especially if the form factor of the device itself makes it challenging to deliver a great and intuitive interface in-situ.

In this regard CarPlay is evidence of success - a sufficiently interoperable car that allows users to bring their own context and ecosystems.

CarPlay is only evidence of failure if your expectation is that the car should provide a comparable ecosystem to Android or iOS - one that must also somehow follow you in your pocket when you leave the car.

I've always been interested in the concept of using the filesystem more thoroughly like this, but sometimes I wonder about the value of it, and if pulling on that thread could get us something even more interesting.

Take this, for example:

> s3.put_object(bucket, key, data) -> cp file /s3fs/bucket/key

The S3 call is tooling over an already lower level operation - an HTTP PUT request. The function tooling is added /because/ it makes it easier to call correctly. You could choose to use the underlying HTTP request directly if you wanted to. The function approach may add type safety and additional client-side validation/logic that can't be expressed in the underlying API (HTTP or FS).

In some ways we can think about the FS as an RPC mechanism with service/resource discovery (LIST operations) and a fixed/limited set of functions (READ, WRITE, SEEK, etc). Perhaps a more interesting 'universal interface' would be a broadly supported RPC mechanism with the FS operations as an adoptable interface that any given resource could support. That way an S3 implementation could choose to implement the FS interface if it wanted to, and an AI agent could discover the additional functionality offered by the other interfaces it supports. Probably a pipedream .

Yes that's true, but there's effort to consider on both sides of design decisions like those TypeScript has made. Much of the compile time behaviour comes from the decision for TypeScript to be incremental on top of JavaScript. That allows you to start getting the benefit of TS without the effort of having to rewrite your entire codebase, for example. Having used TS for many years now I feel that the balance it strikes is incredibly productive. Maybe for other folks/projects the tradeoff is different - but for me I would hate going back to plain JS, and there's no alternative available with such tight integration with the rest of the web ecosystem.

Because adding types adds constraints across the codebase that detect a broader set of mistakes. It's like saying what's the point of putting seatbelts into a car if they only work when you're wearing them - yes you can use them wrong (perhaps even unknowingly), but the overall benefit is much greater. On balance I find that TypeScript gives me huge benefit.

No tool is perfect. What matters is if a tool is useful. I've found TypeScript to be incredibly useful. Is it possible to construct code that leads to runtime type errors? Yes. Does it go a long way towards reducing runtime type errors? Also yes.

I wonder if there's a correlation here with new versions of iOS being released around the same time as new phones? Is it possible that OS optimization takes a back seat to bug fixes during the run up to release then subsequent point releases improve performance?

I'd argue that TNG embodies your guess in many ways - many of the corridor and living area sets look like relatively normal, comfortable spaces. The computer is exactly that sublime technology - it's there when they need it (through a wake word) but otherwise completely invisible.

I don't see anything in the parent comments referencing or advocating for 0% tolerance speed enforcement. In the UK speed limits are typically enforced with a 10% grace factor.

Hey all! My team and I have been working on a fully integrated AI assistant for our Mattercraft tool. It's a 3D development environment for web content - our aim is to find an efficient and expressive intersection between the development experiences of game engines, and those of frontend web development. The AI assistant is a fully integrated 'Cursor-style' workflow that gets the benefit of additional knowledge and context that Mattercraft has about your project. Would love to get folks' thoughts! While Mattercraft itself is already general release, we're launching the AI assistant in a beta. If you'd like to try just drop me a line at connell <AT> zappar.com.

I wonder if, in the pipe dream that email were magically replaced by something more modern, we'd use something like markdown instead.

We do for some elements of our pipeline. WebGPU will give us more opporunity for this in the future too but right now we need broader device support unfortunately.

We have tight inner loops over large numbers of pixels - in some cases optimized to the level of careful register choice and SIMD

We do high performance computer vision in the browser (at 30/60 fps) that's an order of magnitude faster in WASM than JS. It simply would not be fast enough without WASM.