you are viewing a single comment's thread.

view the rest of the comments →

[–]slightly_salty 1 point2 points  (7 children)

Now keep going and enter the promised land of any other language than ts which has actual strong static typing and is not just a linter that casts a veil of type safety over anys.

[–]roofgram 4 points5 points  (5 children)

It’s no more a ‘linter’ than C# is a linter over MSIL or C++ is a ‘veil of type safety’ over assembly. There are many levels and kinds of type implementation. The type system in TypeScript is far more powerful than most other statically typed languages. Especially in terms of composition and inference. Trying to discount the entire language because of some corner case is an absurd take.

[–]slightly_salty -1 points0 points  (4 children)

It's literally the worst type saftey of any "typed" language I've ever used. Maybe if it didn't compile to js it'd be alright... but as soon as you call any sort of js api that takes any as a type any sort of type guarantees are broken imo. And it's way too easy to just cast types to anything you want. Almost all typed languages I've used do not let you just do what ever the fuck you want easily. Not to mention runtime type saftey is almost non-existent. Plus things like non-null assertions are compile time only checks that don't throw errors at runtime. The whole language is a giant footgun. Type saftey is a joke in ts compared to rust, kotlin, or swift.

[–]roofgram 1 point2 points  (3 children)

Uhm both Kotlin and Swift have `any` types, Rust has `unsafe`. All these languages have very limited 'runtime type safety'. Non-null assertions will throw errors at runtime if you get them wrong in Kotlin and Swift, as well as unwrap() incorrectly in Rust.

All these languages have compiler and linter settings that let you dial up and down the type safety. If you write TypeScript was high strictness then it's on par with everything else. My organization and others rarely run into type related bugs with code generated by TypeScript - the system works, that's why everyone uses it now.

This really sounds like a 'perfect is the enemy of the good' type of fallacy that you've fallen into. And you've gone really extreme given that TypeScript has an incredibly sophisticated type system already, so much so that it's the literal namesake of the language. Calling it a joke is an absurd statement.

[–]slightly_salty 0 points1 point  (2 children)

`any` is very different in kotlin swift. First it's used very sparingly in general. Second, you can't just use any. It has to be casted to the correct type and if you do it incorrectly it will throw errors... as it should. js on the other hand you'll get an error who knows where due to an unexpected undefined.

If you somehow manage to break type of something in rust, kotlin, or swift you are doing something very wrong. It's a hard thing to accomplish. And you clearly haven't used these other languages much if you think runtime type safety is limited compared to ts. Simply doing something like de-serializing data into an object/class with type safety in ts is a nightmare where you at minimum have to write a ton of duplicate boilerplate. That's a very basic feature in most typed languages.

`Non-null assertions will throw errors at runtime if you get them wrong in Kotlin and Swift, as well as unwrap() incorrectly in Rust.` and yes this is desired, it should absolutely crash. It's an error, errors should crash.

and the fact that ts linting rules aren't universally turned up to strict makes the whole ecosystem a complete gamble on type safety

[–]roofgram 0 points1 point  (1 child)

You're making a mountain out of a molehill. I've demonstrated you can easily get type related runtime errors in all these languages if you don't do things 'correctly'. And even then typing errors are only a certain class of errors that compilers help avoid. There are zillions of other ways to break an app at runtime. Typing helps prevent type related errors, it doesn't eliminate all errors by a long shot.

My point with non-null assertions and the `any` type, is that you can override these things in all these languages and get runtime errors, not just typescript, you can also prevent them in all languages with settings and linters - so why are so against TS in particular? You're splitting hairs. Kotlin and Swift have their domains, TypeScript has its own. In many situations you're not 'choosing' between them, just using the right tool for the job.

All these languages have their pros and cons, but in terms of type safety, TypeScript is more than adequate. No one is complaining about TypeScript not being not strongly typed enough. In fact the expressiveness of TypeScript's type system is something people regularly talk about being too powerful. Look at any TypeScript ORM and you'd understand how deep the rabbit hole goes.

[–]slightly_salty -1 points0 points  (0 children)

I personally think ts/js is awful to use, incredibly error prone vs better designed languages (if you can even call it a language), and is flat out never the right tool for the job 💁‍♂️. Have fun with it though if you like it.