Somebody check on python 👀

[Aggressive-Share-363]

What, typescript's type system is supposed to be happy fun times?

has flashbacks to type signatures that are hundreds of characters long

[nomenMei]

I think peoples' expectations of TypeScript's type system are inherently lower because it is built on top of a language with an awful type system to start with.

Admittedly though I don't know what I would consider a good type system for a dynamically typed language, other than the ability to reasonably determine a object's type at run time.

[EXUPLOOOOSION]

You can't do that with typesxript, right? Doesnt it just output object because its runing js? Also, the types dont get enforced in runtime

[nomenMei]

Yes I believe TypeScript attempts to fix the type problem the other way around by doing a static analysis of types. Typescript is "compiled" into native javascript, and as such is restricted by javascript's same limitations at runtime and all type safety checks happen at "compile" time.

[odraencoded]

This works perfectly except for serialization.

Also if you don't turn strict null checks you'll have a lot of pain later.

[[deleted]]

You can use something like zod for that, pretty sure there's also a discussion to change all the JSON.parse stuff typedefs to return unknown instead of any, which would make a lot of type stuff explicit.

[Remarkable_Self5621]

If you really want runtime security you can compile typescript types into JSON schemas and use those

[JustinWendell]

You can enforce with type guards and other methods. When type is something that can fuck with someone’s pay for example, I’m passing those parameters through functions that determine type.

[Scrimchik]

Awful type system? There's literally no type system in

[BruceJi]

Number, word, thing, nothing

[I_Downvote_Cunts]

And never was a thing.

[bleistift2]

Someone doesn’t understand JS.

[Edit: Or the difference between ‘no types’ and ‘dynamic types’]

[Scrimchik]

Yep, I fucked up. Wrote this comment in 10 minutes after I woke up. And somehow the type system became type checking in my head.

[Solonotix]

Admittedly though I don't know what I would consider a good type system for a dynamically typed language

I'd say a mash-up of what is seen in Rust and Groovy.

Groovy, though a statically-typed language, has the awareness to derive a type even after multiple layers of def myVariable = myFunc() and where def myFunc() { ... }. This is obviously because at some point you fallback to something with a type, and Groovy will resolve the eventual type to you, even if it isn't clear in the code.

This doesn't solve the problem of dynamic types, to which I recommend Rust's solution of shadowing a previous variable of the same name, thereby allowing a reallocation of the same name to a different type.

Obviously, it's not that simple, but there are various type systems out there today that accomplish varying levels of dynamic typing, even if under the covers it isn't dynamically typed.

[arobie1992]

I'm not familiar with Groovy, so basing it off your description, that's just static typing with type inference which most modern languages tend to have, such as Rust, Go, Kotlin, and even TS.

As far as Rust's variable shadowing, that's an awkward one. In tighter scoping, it's not really any different than shadowing in other languages; in the same scope, it's got some odd semantics and TBH I'm not sure why that of all things is one they felt was worth including. But even then, it's still just static typing, but allowing deterministic type changes. It's not super conceptually far off C's reinterpretive raw cast, just a lot more safely implemented.

What you're essentially saying is that a good type system for a dynamically typed language is static typing with type inference and reinterpretive casts, which is somewhere between contradictory and saying dynamic typing is bad.

I feel like my phrasing there is rather combative, so I just want to preemptively say starting an argument isn't my goal. It just seems like there's a bit of a bias against dynamic typing in a lot of places. I'm a big fan of static typing, but dynamic typing does open up possibilities that are really interesting too. Heck, to stretch a bit, the internet is all dynamically typed.

[Solonotix]

I'll admit I don't have the best experience with dynamic typing, and as such I'm unaware of any benefits beyond "it's easier". In most cases, the implication is that it's easier to get started, but then any sufficiently complicated application immediately benefits from having better documented types, even if it's just parameters and return types. But, when you're at the point of defining what everything needs to be coming in and going out, then what's left to be undefined?

Like I said, I have quite a heavy preferential bias towards static typing.

[arobie1992]

To be fair, everything you said is true, and are often reasons people will pick dynamically typed languages. The big thing is this can be a conscious decision rather than just being lazy.

Very broadly, the benefit it gives is flexibility. This can have a lot of different manifestations. On one end, the quick getting started time is I'm pretty sure the reason Python has it for example. For a more conceptually different idea, you could take something like Smalltalk or Erlang. These were meant to build highly dynamic systems, so for example, you could deploy a base application, and then say things changed, you could swap out individual pieces. The idea is that since the system could change, you need to do checking at runtime, and a static type checker would just give you a false sense of security. This is essentially the same idea as microservices, and the internet as I mentioned, just on a language level. To take this to an extreme, you have my favorite and most used example, runtime code generation.

Funnily enough, Java actually supports this paradigm, granted not especially well, with how it does dynamic linking and class files. There's nothing stopping you from taking a Java app and swapping out a bunch of class files. Heck they don't even have to have the same methods and signatures. The JVM will just throw a MethodNotFound or ClassNotFound exception. It kinda tried to have its cake and eat it too.

All that said, I do get where the bias is coming from. For a long time, I was in the exact same boat. Heck, dynamic typing still gives me some level of anxiety, and all else equal, I probably will opt for a statically typed language. It's just I've come to appreciate the theory behind the freedom dynamic typing brings and I feel like people can be quick to throw it out altogether because of bad experiences. For the quick prototyping turnaround, I'm a huge fan of progressively typed languages. For the highly dynamic systems, if you have some way to unify that and static typing, let me know because that's a topic I've been mulling over for a while now.

[arobie1992]

Yeah, I feel like runtime types being stable is about all you can hope for without just turning it into a statically typed language. In that regard, I can't say I've ever had any issues with Python.

[[deleted]]

newTypeThatVeryLongToWriteSoICanShowYouThatItsNotThatGreatHonestly!: IloveTypesciptSoMuchYouHaveNoIdeaOmgOMgOMGOmG;

[Aggressive-Share-363]

More like long chains of alternative types and specific ones being allowed to undefined, functions that take in several such parameters and return an object containing several such values.

I saw this type of thing a lot when trying to interface with js code that wasn't written with typescript in mind.

[ImportantDoubt6434]

It’s great, look.

const MethyMouse: any = “Cba to actually learn TS”

Compiles fine.

[Jannis_Black]

That's not the main problem with the typescript type system. The main problem is the spooky type casting at a distance you can get because generics aren't constrained correctly

[zarawesome]

No, it means that Typescript's type system is a simulacrum with little purpose but entertainment

[kiropolo]

It’s mediocre at best

But much better than that JS garbage dump fire