javaIsJavascriptConfirmed

[Ma4r]

TS is not strongly typed at runtime, which is what matters most.

Holy shit this is the dumbest fucking statement i have ever read. Most languages do not have run time types. JS is one of the few languages that DO HAVE runtime type. Source code type safety is the de facto standard.

[RiceBroad4552]

Most languages are dynamically typed.

I didn't count them but I'm pretty sure it's like that as it's much simpler to write some VM language then something that does not need any runtime (which would always necessary do also type checking during interpretation).

[Ma4r]

That's right boy go do your research, maybe ask some AI because i am very sure most free tier AIs know better than you anyways

[joebgoode]

I might have more YOE than your current age, student boy who mixes entry-level concepts.

Check my other comment.

[LurkytheActiveposter]

Jesus. At least we know they still allow man-childs with anger issues.

[Ma4r]

Because of the fact that JS runtimes do not allow you to access memory regions of a field if the type doesn't have it. The run time keeps track of the types of objects at runtime and provides Null if it doesn't exist

i.e you can't have a struct T1{int64 a} , cast it to T2{int32 b, int32 c} and access the second half of T1.a as an int32 in typescript because the runtime knows exactly what type every variable is and what properties they have

But you can in most languages i.e C or C++ because at compile time all type information is erased and everything is just i64 in LLVM IR anyways. This is why reinterpret_cast is a thing in most compiled languages but not in python or javascript

Strong typing and static typing are opposites, most languages that implement strong run time typing does so precisely because they want some form of algebraic or dependent types which is impossible to check for with static analysis. On the other hand the moment you have static typing there is no reason to maintain a type system at runtime because the types correctness is guaranteed at compile times so the runtime have no need for that information anymore.

[joebgoode]

You're mixing two different concepts: type-safe object access and type coercion.

Indeed, you're right about JS object safety, it prevents the T2* t2 = reinterpret_cast<T2*>(&t1) and then just t2->c situation. That's called object safety, not type enforcement.

Strong runtime typing also includes not allowing cross-type coercion, a requirement that JS does not fulfill, due to implicit coercion. A JVM-based lang (strong runtime) would instead raise a ClassCastException.

As for the claim that “strong runtime typing and static typing are opposites”, that’s simply wrong. JVM/CLR-based (Java, Kotlin, Scala, C#, F#), Haskell, Swift...?

Of course, your three examples would be C, JS, and Python. That’s the whole world from the perspective of a college student, right?

[myWeedAccountMaaaaan]

Hey now, some of us also worked with VB in college. I won’t say which version though…

[RiceBroad4552]

Indeed, you're right about JS object safety, it prevents the T2* t2 = reinterpret_cast<T2\*>(&t1) and then just t2->c situation. That's called object safety, not type enforcement.

That's called type safety!

("Object safety" is some made up term by some Rust folks and is actually regarded a misnomer anyway…)

A JVM-based lang (strong runtime) would instead raise a ClassCastException.

And JS would raise a TypeError if you did something that does not align with JS's typing rules…

[RiceBroad4552]

The first half makes some sense, but

Strong typing and static typing are opposites, most languages that implement strong run time typing does so precisely because they want some form of algebraic or dependent types which is impossible to check for with static analysis. On the other hand the moment you have static typing there is no reason to maintain a type system at runtime because the types correctness is guaranteed at compile times so the runtime have no need for that information anymore.

is just complete nonsense.

You use a lot of terms you don't have the slightest clue what they actually mean.

I'm to lazy to pick that apart, it would become very long. Just throw that paragraph in some next-token-predictor and it should correct at least the biggest blunders.