If they really need to guard the thinking output, they could encrypt it and store it client side. Later it'd be sent back and decrypted on their server.

But they used to return thinking output directly in the API, and that was _the_ reason I liked Claude over OpenAI's reasoning models.

Even with strict flags on, there are failures. A trivial example:

  function mutateArray(
    arr: (string | number)[]
  ) {
    arr.push(1);
  }
  const a: string[] = ["one", "two"];
  mutateArray(a);

a is now a string[] with a number inside

Woah, that's quite an issue. The equivalent code in Python doesn't typecheck, since `list` is invariant and hence list[str] doesn't fit list[str|int]. Unusual for TS to handle types worse than Python.

Very interesting. I’m shocked the typescript creators built a system with this failure mode. I guess the solution here is to have tsc change the type of “a” after the call to mutateArray, unless the arr argument is marked as readonly.

Is there a name for this failure mode?

I think the problem is the union argument type - intuitively we read "array of strings OR numbers", but actually it means "array of strings AND numbers". Probably generics would be more appropriate here, with the type param constrained to string or number. Then tsc would also complain about pushing a number without checking the item type before.

If it's an "array of strings AND numbers", then it should not be allowed to call the function with a string[], because those are different types.

That would be the sound way to do things, but it's also surprisingly common for arrays for some reason. It also doesn't get checked compile time in Java, although it does throw an exception because the arrays are type-enforced at runtime at least.

This compiles fine:

    class A {}

    class B1 extends A {}
    class B2 extends A {}

    public class MyClass {
        public static void main(String args[]) {
            A[] array = new B1[1];
            array[0] = new B2();
        }
    }

That’s barely scratching the surface.

In TypeScript the following is also valid:

class Something{

    value: Number

}

class SomethingElse{

    value: Number

    foo: String

    bar: SomeOtherThing[]

}

function AddSomething(v: Something)

{

    v.value += 1;

}

var ex = new SomethingElse{

    value: 3,

    foo: “TypeScript is fake types”,

    bar: []

};

AddSomething(ex);

Why does it work? Because in TypeScript as long as you have a “shape” that fits, it’s the “same type.”

Complete and utter insanity to me, to pretend there’s any real type checking, when types are entirely fake and made up.

That's because it's structurally typed (as opposed to nominally typed). I don't happen to prefer it, but I don't think it's fair to conflate that with unsoundness like the example given above; it's totally possible to have a sound structural type system. TypeScript doesn't happen to be sound, but it's not because of that.

Structural typing is great. It's the verified version of duck typing.

You can even get nominal typing with branded types if you need it. (Like for the newtype pattern)

In TypeScript it's called "bivariance", which sounds very programming language theory like, but is not a term typically used in academic contexts, since it is unsound almost by default. It's described here: https://www.typescriptlang.org/docs/handbook/type-compatibil...

Key sentence in their justification seems to be:

"allowing this enables many common JavaScript patterns"

Honestly at this point they should make a new strict "no js" mode, as the ecosystem likely has reached a tipping point where you can get by without mixing typed and untyped js at compile time. Wonder if targeting wasm directly would help ensure those boundaries are ensured...

https://www.assemblyscript.org/ is pretty darn close, but it would probably be better to converge and not split communities

I'm not aware of a name, but I'm also curious if there is one because I had a hard time searching for it.

I came across it on ThePrimeagen's YouTube channel: https://youtu.be/u1WmiqlrqL0

I asked an LLM and it described the problem as "covariant typing of mutable collections" or "unsound covariance". I'm not mathematically educated in this area but that sounds right?

Yes, that's correct. If you're curious for a slightly more concrete source, Wikipedia covers this reasonably well (although citing one often decried source to validate another might not be particularly convincing to some people): https://en.wikipedia.org/wiki/Type_variance#Arrays

Yikes. I've only been using ts for about a year, I had no idea this was considered a "valid" case. Seems like a type error to me. I wonder how they justify this?

I agree with this take. Desktop Linux is better than ever and I can do just about 100% of what I need on my Linux PC. I still use macOS regularly and even Windows sometimes, but I’m not too worried about Apple or Microsoft locking things down. The more they do, the more I’ll just use Fedora where the same apps I need are available.

The most critical apps for me on mobile are banking, payments, transportation, and messaging. Banking I can’t do much about. Payments I can still handle with physical cards. Messaging is getting better thanks to people adapting proprietary services to Matrix, so with some effort you can use one open source client to reach them all.

Transportation is the area I’ve been working on. I’ve been getting MapLibre (an open source map rendering library) running on Compose Multiplatform, including Compose Desktop (so map apps built in Jetpack Compose could extend to Linux based phones like Librem) and also on Huawei’s HarmonyOS. If I can cover my everyday needs with open tools, then walking away from the Google/Apple duopoly stops being a thought experiment and starts being a real option for me.

Electric cars are heavier due to the battery.

It depends on exactly which car you are comparing. The Tesla Model 3 is somewhere around 3500 lbs, isn't it? That's pretty average for a car these days.

And there are plenty of big SUVs that have a similar weight to the heavier EVs.

Besides, you can't assume that electric cars use the same tires as non-electric ones.

There is a huge range of tires out there from extremely long wearing ones to sticky ones that last a fraction of the time.