41.39 At that moment, he struck me as the Architect from *The Matrix*-calm, calculating, and omnipotent, weaving the fabric of this digital reality. Honestly, that’s probably one of the highest compliments I could give. Ø
"Removing type checking from your running programs is like wearing a life jacket for your practice emergency drills and then taking it off as soon as your ship was really sinking" RIP Typescript. The rot goes too deep
That does not apply. Neither is what he's talking about specifically an issue in even Javascript (Javascript and by extension Typescript will throw an error if you access outside of array or list limits) , nor is it difficult to break the type system of Java for that manner (just inherit some class and override its methods to do stupid shit, which is actually not difficult with many Java Classes as they're often quite complex in amalgation of what they inherit and inheritance gives you access to their whole inner workings that only work correctly in specific configurations). Typescript actually fixes the general issue he described in this talk, which is something that Java, which he praises so much to this day doesn't. Well, I guess yeah it will not do random stuff, crashing and burning alone is better than setting fire to the whole neighborhood, but it's still very difficult to write a program in Java that DOESN'T in some "bordercases" crash unexpectedly. And on any Computer that uses a modern OS the behavior of code in eg C that doesn't do any null checking or Java is pretty much identical. Because the nullptr is part of a forbidden memory range and your program will be terminated by the OS if it tries to dereference null. So unless you do some embedded stuff (with Java? Youre crazy), Java, in terms of NULL specifically is on one level with C and C++, and worse than that Typescript you seem to hate so much.
@@9SMTM6 wow, you took that personally. "Type checking" is a bit broader than bounds checking and null, so I don't really feel addressed by those paragraphs at all. If you wrote in more detail about TYPESCRIPT then maybe I'd have found some value in it.
@@ezg5221 the primary topic of that talk was null. And Java, unlike he theorized, has YET to adopt any solution to unexpected null exceptions. That is unlike C#, and namely Typescript. Then, that paragraph you mentioned was talking about bounds checking and the ability to disable it. There are only 2 languages amongst the most popular ones these days, that do not bounds check array access per default, and that is C and C++. But hell yes I'm taking it personally if people make stupid assertions. I don't actually do any Typescript of late, these days it's been Kotlin, Python and Rust. Rust being my favorite of the bunch, it famously has the most... "correct" type system amongst popularish languages. You know what is the language I feel the 2nd most certain that it's type system enforces that no type errors happen that stop program execution unexpectedly? Typescript. I used it with fairly strict rules, perhaps thats where your mistake was, but it has en excellent type system. It's quite different to how other languages do types, but once youre used to it its easy and ensures correctness of what it promises. You know why Kotlin isn't that language? Because of fucking Java. Kotlin itself is nullsafe, but Java isn't, and as kotlin selling point is Java interop, its null safety isn't ensured at the interop boundary, breaking it. But MORE importantly, Inheritance based type systems are horribly broken. Kotlin also improves on Java in that regard, by default you can't inherit from its classes, breaking Kotlin Class instance typesafety, but again Java is here to ruin the party, FORCING you to use Inheritance in many APIs, and having super popular packages like spring regularly break type safety in dirty ways, like with JPA implementations. All this leads to Kotlin, by fault of Java, making promises it can't hold and generating random fail conditions you'd never expect, like serialization of some objects you obtained from the database randomly failing serialization. You might think Typescript with many Javascript libraries should have the same issue, but that has not been my experience. Javascript libraries due to the historic lack of safety offer simpler APIs, and they have well maintained API descriptions in Typescript that tend to be on point, because they only make structural promises. Yes, if people put type assertions everywhere that breaks things, but Java isn't different in that regard, and the simple solutions is: Don't fucking do type assertions unless you the fuck know what you're doing, and it's easy to find the sources of the resulting issues as it's these type assertions. Some libraries like Redux make it difficult to do that, but I and plenty other people have found their ways to archive it. Ive yet to find a way to use Java APIs in anything but toy projects without it breaking. It's type system is just not expressive enough, while being much needier than Typescript on top of it. The ONE area where typescripts at Runtime missing types are annoying is at network APIs where they require a bit more effort to ensure correctness. I don't know what you want to hear from me regarding Typescript. You would have to ask questions or criticize it, I won't try to guess what your issues are, as I said I've solved most of them. I will sleep now tho.
@@9SMTM6 I've re-watched it, and the paragraph was about pointers knowing what types they should be pointing to, but in the context of a typed array, it's either right, null, or out of bounds, yeah. And you know what, I've seen enough 'Promise's in my team's codebase to not question it, but I think I've been looking for the 'unknown' type this whole time. That basically handles my worst-case scenarios. I've also been treating function signatures like contracts, which is why I wasn't comfortable with their types going away, but I guess typescript can make enough guarantees about earlier checking, I'm just pessimistic.
@@ezg5221 hmm, I ale also rewatched it, and while he did also speak about this, I just inferred that he was only talking about array bounds checking, and while I still think that that was what he was talking about, even if he wasn't, it's all that is relevant. Reason being that due to the nature of how things work, array bounds checking being a dynamic runtime check, it can lead to type safety issues, WHILE typed references are checked statically by every compiler I know (that has a concept of references or pointers and doesn't abstract them away, the latter which still is typesafe in modern languages), meaning that there's nothing to leave away at Runtime, so it's perfectly safe. This is actually precisely how Typescript works, it checks stuff statically at buildtime and drops away at Runtime. Which is, btw, also how C, C++ and also Rust work. C++ and Rust have some extended concepts for dynamic dispatch where you have some type information at Runtime, which is actually the foundation for anything in eg. Java, but for these languages it's the exception. And yes. "any" is poison in TS. And "unknown" is fairly amazing, I was there when it got added and immediately was able to use it in a variety of places. Though it's mostly where I don't use the result, eg. when I want to accept functions that may or may not return whatever they want as I don't use the return (which I do for handler functions, allowing perfectly safe reuse of methods). As I said I used TS with strict rules, there is actually a list of Type checking options on their website (which I unfortunately can't link to as RU-vid deletes comments with links). But I've got to admit, I just realized that a small part of the checks that I require in TS are not provided by it but by ESLint, namely in my projects its forbidden to explicitly use any, combined with a TS rule that forbids implicit any, any is gone from my code basis entirely (well, with exception of badly typed library interfaces, but I can trace where that comes from and retrofit these). I used typescript with quite heavy type inference, with heavy reuse of types, in a structural way. That way actually most of my code looks and writes as easy as JS, but is Typechecked in its entirety. It does depend on apparently the presence of ESLint, and if your colleagues block safe settings, yeah, unfortunately Typescript does allow them to do things unsafely. But my colleagues (Java programmers that never spent any time learning TS) used it unsafely in a large code basis, and I was able to pice by pice convince them to enforce stricter rules, and now they're better off for it. I was also able to retrofit typesafety into that code basis by using the tools Typescript gave me (and at times a few other tools like regex search and replace and ESLint). I was able to do that as a Junior dev that had only studied Physics, that before that point had mostly used Python (back then there was no type system at all in Python, which they actually retrofitted these days, actually heavily based on TS, though unfortunately much more difficult to enforce). That is a success story in my eyes, and the reason I really like Typescript, as you probably spotted. It's not quite as correct as Rust, but with Rust the overhead for correct typing is a decent amount higher (due to it being a nominal type system as opposed to Typescripts structural type system which makes less promises but is able to infer most stuff from context).
Support for null safety operators, or optional types (which are easy to get if you have sum types in your language) Indeed, when he starts talking about classes as disjoint unions of composing classes, he's very close to sum types.
Make all references valid. One tool to achieve this is by having algebraic data types, you can return Cat|Null if you want to return a Cat sometimes, but keep the option to have it uninitialized. In Java style languages, every instance of Cat is actually Cat|Null, and you have no way to enforce that you actually, seriously, for realsies this time, want a Cat. You can check each "Cat" at every handoff point if it's null in hiding, which is pointless and error-prone manual labour. You could instead make it explicit, and also guarantee that every Cat is actually a Cat.
@@monk3y206 Rust has Option, which is an enum (or, for Rust, a tagged union) with variants Some and None. That makes two things explicit: 1. With a variable of type Option, you may or may not have a value of type T, and can use pattern matching to handle it appropriately. 2. With a variable of type T, you do not have to guess whether it is T or null, which is the issue @gJonii points out with Java.
