class Foo {} class Bar{} function ensureFoo(foo: Foo) { if (foo !== null && !(foo instanceof Foo)) { // Should never happen, right? foo must be a Foo! throw new Error(); } } ensureFoo(new Bar());
... what if you want to build a web app? Gotta get to JS somehow. I'd rather use any of those if possible. I'd rather literally use just plain JS than TS.
But honestly Kotlin appears to be my lord and savior, I hope it takes off.
Blake Stewart
>>no compiler error Because of the &&, the compiler will optimize and not let you know there's a problem until runtime. This is well known, CompSci 101 knowledge.
Matthew Reed
Would if I could. Work is stupid and is migrating to TS for all the frontend and node stuff we have. I'm trying to convince them Kotlin is superior but I fear the ship has sailed.
Asher Sanchez
The whole point is that >the worst thing known to man Is vanilla Javascript.
Typescript let's it suck just a bit less, for people forced to use it.
Matthew Young
can you explain, why does it let you pass a Bar to a function that says it only accepts Foo?
Jace Roberts
The problem with totally different languages like Kotlin and Clojurescript is that every library and third party thing you want to use is going to be Javascript. Even with "bindings" it's terrible dealing with a nice language and also having to deal with a shit one.
Typescript let's you make you own code better whilst still being basically Javascript.
John Nelson
>Js
You realize OCaml can compile to JS bytecode right? Strongest type system you can use next to some kind of purely functional language. There's also 'ReasonML' which is essentially OCaml but with different syntax and extensive libraries for web development made by FaceBerg
Jonathan Harris
yes. javascript doesn't have types. deal with it and stop shitting up js with your garbage tacked on type bullshit that doesn't actually work.
Jace Rodriguez
>Typescript let's it suck just a bit less But its a lie. I'd rather live in reality than in a lie.
Because structurally Foo and Bar are the same (same properties and methods, i.e. none) and TypeScript is structural. If you add a method or property for Foo or Bar it will be an error. But if you add the same method / property to both it won't be an error, they still line up.
There's a ton of other bullshit in TS too, like generics being bivariant. Which is fucking insane, why have them at all?
>But its a lie. I'd rather live in reality than in a lie. then do that retard. typescript is basically conflicting with modern js already. it's dead end garbage.
Wyatt Sullivan
whoa structural typing sounds pretty cool though. sometimes i wish other languages had that
Joseph Peterson
my wife ryuuko is so cute
Aiden Sullivan
>You realize OCaml can compile to JS bytecode right? Thanks, I'll look into it. Kotlin appears to be catching on as a Java replacement, hopefully it gains ground over JavaScript too.
>it's dead end garbage. The community is eating this shit up, doesn't look like a dead end until / if Kotlin catches on. It probably will. The JS community are a bunch of directionless sheep that pick a new favorite every few years. But why can't we just bypass this one terrible meme and go straight to Kotlin?
Brayden Brown
Some languages do, but usually you make an explicit structural interface, not a concrete type. Not every fucking type in the entire program is meant to be structural.
Jaxson Cruz
Look up bucklescript OCaml and ReasonML (note, ReasonML is OCaml) can also bring in C libraries and anything else.
You can also just go balls out and do webassembly now, compiling directly to Javac bytecode, bypassing JS completely. You can do this in C/C++, Rust, OCaml and tons of other langs but Rust and C++ are the easiest right now, esp Rust with it's cargo import this pile of dependencies and presto you have webasm.
John Peterson
probably because it's yet another transpiled shitlang load of garbage that fails miserably at working with other js?
typescript at least has the positives of working with jsdoc and js and offering a LSP server for javascript/typescript and it's also all implemented in javascript or transpiled ts.
Adam Rodriguez
yea
Isaiah Howard
>probably because it's yet another transpiled shitlang load of garbage that fails miserably at working with other js? worked fine when I tried it and its type system didn't stab me in the back
>typescript at least has the positives of working with jsdoc and js and offering a LSP server for javascript/typescript and it's also all implemented in javascript or transpiled ts. not much of an argument when everyone appears to be in agreement that JS sucks
class Foo { getNumber() { return 0; } } class Bar { getNumber(): number { throw new Error('WHAT THE HELL'); } } function ensureFoo(foo: Foo) { if (!(foo instanceof Foo)) { // Should never happen, right? foo must be a Foo! throw new Error(); } } ensureFoo(new Bar());
Just because things are structurally equivalent doesn't meant they're the same
In TypeScript and empty class like Foo{} is equivalent to any. So you basically had function ensureFoo(foo: any) which is why you can pass a Bar without issue.
Try learning something for more than 10 minutes before shitposting with trivial code.
Jose Robinson
instanceof is a construct from JavaScript, JS instanceof expects a value for the right-side operand. x instanceof Foo in JS will perform a runtime check to see whether Foo.prototype exists anywhere in the prototype chain of x. In TypeScript, interfaces have no emit so neither Foo nor Foo.prototype exist at runtime. Plus you short circuted !(foo instaceof Foo) so compiler optimizes it away and gives no warning. Now you run it and everything implodes. Language specs are there for a reason, always go over one in detail and note the defined behavior of everything, such as interfaces
Charles Rogers
>java monkey literally too retarded to understand structural typing
See If the fields and methods line up they are the same. This includes {} but also more complex structures.
>In TypeScript, interfaces have no emit so neither Foo nor Foo.prototype exist at runtime. They aren't interfaces, they're classes. Concrete structures!
>Plus you short circuted !(foo instaceof Foo) so compiler optimizes it away and gives no warning. That has nothing to do with it. Read the thread. And then a book.
I understand it, and that's why I hate it. I understand if I shoot myself in the foot I'm gonna end up with a bullet wound in my foot.
Dominic Parker
My shoes come off at the door, but my roommate wear shoes until he showers and goes to bed. It's one of this nation's greatest weaknesses.
Making wild claims based on something you have no knowledge of? Sounds like typical Jow Forums. Typescript makes sense for JavaScript. It is the way it is because it is meant to integrate easily with existing JavaScript code. It has one of the most sophisticated and intelligent type systems. Typescript is one of the best type systems.
Adrian James
How are you going to shoot yourself in the foot with anything other than your contrived bullshit example? Keep in mind any class in Java can also declare that it extends another class and override a method to throw an error.
Josiah Howard
I meant see
Liam Cruz
I mean if you want a "real" example I can give you one.
function assertInOrder(set: TreeSet) { let last = Number.MIN_VALUE; for (const n of set) { if (last > n) throw new Error('out of order - should never happen'); last = n; } } assertInOrder(new HashSet(10, 9, 8, 7, 6 /* etc */));
You could imagine TreeSet and HashSet are structurally equivalent. But they mean different things.
Chase Lopez
Except that would only typecheck if HashSet has all the fields of TreeSet, including private ones.
TypeScript is fine for the enterprise. You've got assholes who've been working 9-5 as "developers" for the past 25yrs without ever expanding their skillset beyond webforms. Do you want them jumping in head first on your node/react/rx app??? Protip: no, you don't.
My team wrote one of the biggest javascript apps in our city about 5yrs ago when TypeScript was just coming around. As team lead, I needed to guarantee that the shithead "senior devs" who were "senior" because they hadn't applied for a job in 25yrs, didn't mess up. Of course they did. We all did. The app was shit. But it was LESS shit than it would have otherwise been without TypeScript.
As for null, fuck null.
Ethan Long
So you went out of your way to copy over every single field in TreeSet to HashSet? This is literally as retarded as complaining that you can have HashSet extend TreeSet in Java, override the getValues() method to be out of order, and complain about the type system not protecting you.
Juan Harris
I'm a PHP developer. Why should i learn typescript. i fucking hate javascript and coffeescript and script it's horseshit. I hate PHP too but not as much.
Josiah Powell
Everybody who reads TS documentation knows that 'foo instanceof Foo' tests whether foo references an instance that was created by the Foo constructor function, but because of structural typing, even when the result is false the compiler can't conclusively say that foo isn't compatible with the Foo type which is why you use user defined type guards basarat.gitbooks.io/typescript/docs/types/typeGuard.html There's nothing to see in this thread. This is known behavior. Write your own compiler in that outputs TS or straight to JVM bytecode. Problem solved. Call it GNU's Not TypeScript