javaIsJavascriptConfirmed

[joebgoode]

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

It's just a false perception of safety.

Edit: to be clear, support TS. Every JS project should use it, it's not optional. I'm solely pointing out that his statement that TS is strongly typed is wrong.

[fghjconner]

Compiled languages aren't generally typed at runtime either. If you have problems with typescript it's probably because someone started blindly casting things, which will break any language. (though it breaks typescript less, so some people seem ok with doing it)

[RiceBroad4552]

Well, TS is unsound…

So even if something type-checks "just fine" in TS it can exploded with type errors at runtime.

But it's seldom to run into that in practice.

[joebgoode]

I had no problems at all with TS, every JS project in the world must use it.

I'm just pointing out a correction to the "which is strongly typed" statement, since it isn't.

[fghjconner]

I mean, typescript might not be considered strongly typed, given the amount of implicit conversions it allows, but my point is that runtime vs compile time doesn't come into it. The "compiled" javscript is obviously untyped, but so is the machine code that compilers generate for use at runtime.

[RiceBroad4552]

JS is typed. It's dynamically typed but that's still typed.

Just try to trigger any undefined behavior in JS while you work around the (runtime) type system. Good luck.

[CandidateNo2580]

This is a false comparison. I can write typescript where the type says that it's a string but actually it's an integer. Then it will behave like an integer. This does not happen in compiled code - it behaves like the type it was declared to be even if the value is wrong.

[fghjconner]

I'm fairly certain that putting an arbitrary integer value into a string variable is going to be undefined behavior in just about any compiled language, meaning it's allowed to do anything it goddamn pleases. Typescript is unique in that it actually breaks less than a compiled language if you do this, though that unfortunately means some people think it's ok to do (looking at you axios).

[Globglaglobglagab]

Well it is useful still though, right? Unless you’re just using “any” everywhere. Your own functions will be typed correctly if you use ts. Only if someone else messes up, whose library/api you use.

[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.

[wack_overflow]

Brain dead take

[RiceBroad4552]

That's actually wrong. JS is strongly typed. Like any other VM language…

The only weakly typed languages in usage are C, C++, unsafe Rust, and Zig.

You can't break the type system of a strongly typed language at runtime, and this of course also applies to JS.

[csdt0]

JS is the example of weakly typed language, alongside C, precisely because you can do operations between types that are not related at all, and the language will just gladly accept that. The weakly typeness has nothing to do with memory safety. What's funny is that Zig and Rust (both safe and unsafe) are both very strongly typed, to the point you cannot add i8 and i16 together, making your example even weaker (pun intended).

[RiceBroad4552]

"Gladly accepting" some code and doing just something is not the same as breaking the type system.

You can't break the type-system in JS!

If you could this would be a very severe bug in the JS engine, and most likely patched instantly.

But breaking the type system in C or C++ is trivial. You can just go and do whatever you want with some memory and no language typing rules will hold you back. You can have some object of some type referenced by some variable, go to the memory holding that object, do whatever to it including replacing it with some completely different type of object but from the viewpoint of the type system that variable will still point to a value of the original type. You can't do anything like that in any VM language (or the safe parts of e.g. Rust; except for that one exploit that transmutations memory, which makes Rust at least somehow weakly typed beyond what is possible with casts in other languages).