11 ms·

Javascript being fast as Java and coupled with Typescript the future of Java doesn't look very bright.

by ithrow 5y ago

jetsetgo 5y ago
Please stop. These kind of remarks just brings the worst of out community. JAVA is and will be fine. It's doing better than ever.
ragnese 5y ago
TypeScript is awful. Like, I shit on Java all the time, and I WAY rather work in Java than TypeScript. TypeScript's type system is so utterly broken that I honestly don't know if my code is ANY more robust than if I had written it in JavaScript. Record<> is broken/unsound: https://github.com/microsoft/TypeScript/issues/45335 https://github.com/microsoft/TypeScript/issues/45335 Generics are wonky and sometimes wrong: https://github.com/microsoft/TypeScript/issues/31006 https://github.com/microsoft/TypeScript/issues/31006 The `readonly` keyword does absolutely nothing: https://github.com/microsoft/TypeScript/issues/13347 https://github.com/microsoft/TypeScript/issues/13347 Arrays are covariant in their type param, so I can pass a `Dog[]` into a function that accepts `Animal[]`. If that function adds a `Cat` to the passed array, the compiler is perfectly happy, but we'll see a runtime error. TypeScript is actually so bad that it might have honestly made JavaScript worse, if that's even possible.
- deleted 5y ago
  [deleted]
- Scarbutt 5y ago
  It's a shame that something like Typescript is and will dominate the static typing JS ecosystem/industry instead of something simpler and sane like Rescript.
  - ronenlh 5y ago
    Rescript is sane but I wouldn’t all it simpler. It can be really hard to do trivial stuff with it. I felt I had to study OCaml to understand it.
    - quaunaut 5y ago
      I think it gets pretty close, but admittedly its handling of unknown objects is just downright bad. Also, somehow, the tooling for it has one of the best features around(compiling to readable JS), but all other tooling is completely absent, and frankly, bad.
- quaunaut 5y ago
  I generally agree with everything you're saying, after extensive use of Typescript. Its safety guarantees usually only help within extremely tight bounds, and there's surprisingly little that it catches that couldn't be inferred directly. However, a question: > Arrays are covariant in their type param, so I can pass a `Dog[]` into a function that accepts `Animal[]`. If that function adds a `Cat` to the passed array, the compiler is perfectly happy, but we'll see a runtime error. I don't think this one is true anymore, assuming you type it correctly. I've provided an example[1]. --- Separately however, I think it's worth noting that I've been playing with the idea of doing a project in plain Javascript again, to see if I feel any serious productivity losses. - [1]: https://www.typescriptlang.org/play?#code/C4TwDgpgBAwghsKBeKBvAUFKpIC4oDk8wBANJlAK4DOE1AMgJbDAQBOARgPYAe+3XADYQ4AO3QBfdOhzQAIlwDmyNBVn4CCxWQoALLjQgc2XANYRR+YG0oRJ02VACCoxgFs4glVqgAfWAjSAPQAVCGYIVAAKrqM1FBcotBsEMCUbKLxYlAABi7ungDaALo52OAQAHQRQegAxonUiHAAJi3UxACSogBm7CktKgAUYgWC1Pj5HoIlAJTIAHyqWKPT1JVgNLpDqOqExGRUtAzMrJy8VjYQErMUKWkZUKue1Pah4VCRMXEJSVD36UyUAA7roEBAAG7scqQKAgAxQRRwKFQZikJ7xQSJZRweLMKAQHisUTtXJTTw5SrOeLwyhQOrZWgQdH4-pcNjxYBgxD41qkhmIDgQBmGVGICGMITgzm6aANTLWOCMUSILg9J5QaiUDiyaqfWryppPNodBAAUSJFlJKAAPFECZaSfFyYIFiNXGt8FE5otlk8PS8NlsdnsiAhDoYTix2Nw+Ngrjc7qlAf6xq8pPVGogWkoJlAtCUVIVdhUNFpDvpDMYzBZLrYJMVMwqoD0uFwVHzTcBun02AMhjnFNRbobBXA2B2TcQLcT2gPc7cgA https://www.typescriptlang.org/play?#code/C4TwDgpgBAwghsKBeK...
  - ragnese 5y ago
    > I don't think this one is true anymore, assuming you type it correctly. I've provided an example[1]. You are correct that using a generic does fix the issue. But you called that "correct". But why, as a code author, should it be my responsibility to understand type theory better than my compiler? Because, according to basic type theory (to the extend that I understand it), TypeScript is allowing an operation that is literally incorrect in the first example. (mutable) Array types must be invariant in the type parameter. It should bitch at us for both examples. And this won't happen with just arrays. It'll happen if you do the same thing with an object with a field. E.g., instead of `Animal[]`, we could have the function take a `{ pet: Animal }`, and pass it a `{ pet: Dog }`, and replace the Dog with a Cat, causing a runtime error for the poor schmoe who thought he still had a Dog.
- phailhaus 5y ago
  Wild how people can have such different experiences. Typescript is hands-down one of my favorite languages, and I would choose its structural type system over Java's any day. I also use Python at work, and it's like night and day in terms of quality. Every day I have to deal with fundamentally unresolvable issues due to Python's half-baked type hints, when I could be writing much more stable, functional, and maintainable Typescript. Calling it "broken" is complete hyperbole, and no, it's not "worse than Javascript". There's a reason why the entire ecosystem is switching to Typescript, and that's because it is extremely effective at helping teams manage complex stateful applications.
  - FpUser 5y ago
    >"Calling it "broken" is complete hyperbole" Well, when comparing it with strongly typed languages it does look broken for sure.
    - masak 5y ago
      This reply is a good example of how "strongly typed" ends up meaning practically nothing -- except possibly "the kind of type system I prefer". I once attended a talk where the speaker had identified half a dozen axes that papers or projects were calling "strong"/"weak" with relation to type systems. Some were not even consistent with themselves, switching definitions halfway. Type systems are tools, whose formal properties can be described and analyzed in precise detail. Unfortunately, that kind of precision is hard, so semantically empty words like "strong" get used a lot instead. This message is intended to raise awareness about that fact.
      - FpUser 5y ago
        Well one can analyze that type systems are till the hell freezes over. I personally do not care as this precise knowledge (assuming it is formalized and exists) is of zero value to me. When I want to walk I just do. I do not dwell on the details of the walking process. Anyways most likely you do know well what I meant. JS vs C++ for example.
- brundolf 5y ago
  It has holes, mainly because it has to be able to cover existing JavaScript codebases, which for many reasons can be an order of magnitude harder to type than code that's written from the beginning to be statically typed. The biggest holes can be filled via compiler options, and most of the rest can be papered over with the right coding practices (use Maps instead of Records, lint against `any` and type-casting, etc). I haven't encountered the situation you described, but you could probably solve it by making the function generic over TArray extends Animal[]. The rest of what you've said doesn't line up with my experience. TypeScript is an imperfect tool that requires some elbow-grease to fully benefit from. I would prefer a typed language that didn't have to work under its real-world constraints (but not Java, because of null-checking at the very least), but over the years it's caught more bugs for me than I could possibly hope to count.
  - ragnese 5y ago
    Many of the worst holes are indeed because of JavaScript compat. But, not all of them. See some of my other comments in this thread. There's no earthly reason that a `type` should automatically implement Record<string, unknown> and an `interface` shouldn't. That's just dumb and annoying- not necessarily "wrong". However, it's definitely wrong to allow me to pass `const o = {}` into a function that wants `Record<string, string>`. How in the world does TypeScript (with the strict flag set!) think that an empty object is able to return a string value for any arbitrary string key? That's absurd. The issue I raised about arrays isn't just arrays, actually. It happens with object fields as well. See https://www.typescriptlang.org/play?#code/MYGwhgzhAECCB2BLAtmE0DeBfAsAKFEhgGEwAXaAUwA8zL4ATGBFNTfaT6ZSgewHcAFAEoAXNABuvRA3Z4uC6MF7wIvEJQB0IXgHNBAIh4CDwjl1x5LhKNAAieqrXpM4SVOgznOAIzAAnAGsRcSkZOUUuZVV1LR19Az8g029oS0t8RHg6fwAzMGBKaAAJSAAFSgoveS4AB0rxFg98DLwsnPzCksgHXQi6hvs9Fvx8XIBXeGAyRBVuMCRa8fA6CrJBXnFSiDXhfs5eTXqKAF5oeEp+aFJ1sytRghUICk3uiF7oM+qFY-ELq96IhGeHwqEWy3IlDWGzu+EOx00SWCewA9CilLxkLVEBp-NBEDB6nlKNMQABPaAACzAtVqZIAhEA https://www.typescriptlang.org/play?#code/MYGwhgzhAECCB2BLAt... And, the `readonly` keyword has nothing at all to do with JavaScript. Yet, they added this keyword that is completely and utterly useless. To the point that I actually introduced a bug in my own code because I put `readonly` and `Readonly<>` everywhere and expected it to actually help me. It did help me... most of the time. And then it didn't. Because it turns out that you can always take a Readonly value, assign it to a non-Readonly variable and then just mutate the hell out of it, and the compiler won't even bat an eye: https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgJIFt0FcxwEYA2EAYgPanIDeAsAFDIPJQRwAmpIBAnsjOQFzIQWdHmh0AvnTqhIsRCgCyOfETIUa9Rn1KDho8bSm06MLCARhgHZAAs4IVmvIAKHYIzZchEuQCUggBupMCsVHSMyAgcAM5gyKRgttDqgsrezhQAvLzkEYyJyVDqAHQ6yDkAtACMktK00SBxubpomCo+6hXhWgzuyLVG9Y0xpEQlBKQA5m7kZf509o6Zs6R+dCNjEBPTq-NrQA https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgA... That's just... so bad. I don't even know what else to say. Sure, it caught some of my mistakes, but if it won't even catch all of the class of errors that it's supposed to, then I have to basically be just as careful as if I didn't use the feature at all. So, it's not reducing my mental burden at all. If anything, it's just giving us/me a false sense of security and tricking me into thinking that I DON'T need to be as careful.
- skitter 5y ago
  > Arrays are covariant in their type param, so I can pass a `Dog[]` into a function that accepts `Animal[]`. If that function adds a `Cat` to the passed array, the compiler is perfectly happy, but we'll see a runtime error. The same is true for Java arrays. I thought the Liskov substitution principle was tautological when I first heard about it, but it seems like the original designers of Java disagree. Another example (albeit from the standart library, not the typesystem itself) is that if you try to modify a `List` or similar collection, it may throw an `UnsupportedOperationException` because it's immutable - instead of having a superinterface with only non-mutating methods and only implementing that.
  - qsort 5y ago
    > The same is true for Java arrays. This is an unfortunate relic of pre-1.5 Java. The rest of the Collection API types correctly. A type-safe generic alternative is Arrays::setAll. > if you try to modify a `List` or similar collection, it may throw an `UnsupportedOperationException` Again, an historical artifact. `List` is from Java 1.2, you would effectively have to deprecate List<T> for that to work.
    - bobthebuilders 5y ago
      Most of these things in TS are due to historical artifacts too. Namely code patterns that would not work well without them.
  - ragnese 5y ago
    Ugh. You're going to make me defend Java? I'm going to need a drink... First point: Yes, Java's arrays are broken and it offends me greatly. However, in practice, it's much more common to use Lists, which are not broken. In JavaScript/TypeScript "Array" is the equivalent of Java's List, so if you want a dynamically sized, contiguous, collection, you are stuck with the broken thing. Then, the other issue is that, despite my comment's wording, this problem isn't ONLY present in Arrays. It's also a problem with objects, and (I assume) every other non-primitive type. See here: https://www.typescriptlang.org/play?#code/MYGwhgzhAECCB2BLAtmE0DeBfAsAKFEhgGEwAXaAUwA8zL4ATGBFNTfaT6ZSgewHcAFAEoAXNABuvRA3Z4uC6MF7wIvEJQB0IXgHNBAIh4CDwjl1x5LhKNAAieqrXpM4SVOgznOAIzAAnAGsRcSkZOUUuZVV1LR19Az8g029oS0t8RHg6fwAzMGBKaAAJSAAFSgoveS4AB0rxFg98DLwsnPzCksgHXQi6hvs9Fvx8XIBXeGAyRBVuMCRa8fA6CrJBXnFSiDXhfs5eTXqKAF5oeEp+aFJ1sytRghUICk3uiF7oM+qFY-ELq96IhGeHwqEWy3IlDWGzu+EOx00SWCewA9CilLxkLVEBp-NBEDB6nlKNMQABPaAACzAtVqZIAhEA https://www.typescriptlang.org/play?#code/MYGwhgzhAECCB2BLAt... So even a basic object field is broken in TypeScript's type system. What the hell are we supposed to do with this? I do have thoughts and opinions about Java's Collection interfaces, the immutable implementations, etc, but that feels like a whole other topic.
- Zababa 5y ago
  > TypeScript's type system is so utterly broken that I honestly don't know if my code is ANY more robust than if I had written it in JavaScript. You gave three examples that seem relatively rare. At work we use TypeScript to type a codebase that was mostly plain JavaScript, and we write TypeScript as plain JavaScript. It does very well its job of offering use better tooling and compile-time guarantees. If you consider it as a way to statically-type existing JS codebases, it's good. If you consider it as a language on its own, it's not great.
  - ragnese 5y ago
    I only gave three examples because it was a single Hacker News comment and I didn't think I should keep a running catalog of every single hole/issue/inconsistency that I've encountered in the last year of working on a TypeScript project. I gave a few more examples in other comments in this thread. I can go look at the code comments I wrote in my project and come up with a longer list for you if you like. > You gave three examples that seem relatively rare. At work we use TypeScript to type a codebase that was mostly plain JavaScript, and we write TypeScript as plain JavaScript. It does very well its job of offering use better tooling and compile-time guarantees. If you consider it as a way to statically-type existing JS codebases, it's good. If you consider it as a language on its own, it's not great. This is a legitimately genuine question: if you're treating TypeScript as just type annotations on an otherwise regular-old-JavaScript codebase, then why are you using TypeScript rather than just JavaScript with JSDoc comments? Also, I can't quite tell. Are you defending TypeScript's brokenness by suggesting we just don't use all of its advertised features? Isn't that... kind of weak? It's like the joke about going to the doctor: "Doctor, my elbow hurts when I do this." "Well, don't do that!" -- If TypeScript advertises a feature, shouldn't that feature, like, actually work?
    - Zababa 5y ago
      > This is a legitimately genuine question: if you're treating TypeScript as just type annotations on an otherwise regular-old-JavaScript codebase, then why are you using TypeScript rather than just JavaScript with JSDoc comments? TypeScript is way easier to write, and allows to anotate more stuff. We do have some JS that will stays as JS that's anotated with JSDoc, and it's a worse experience than TS. > Also, I can't quite tell. Are you defending TypeScript's brokenness by suggesting we just don't use all of its advertised features? I'm defending the usefulness of the tool, but not its marketing. I think the approach of trying to cover every single usage of JS is not the best, and leads to some complex features and weird edge cases like the ones you mentionned. But for typing plain JS, it works very well. I guess we get a lot of value from TS because static typing is easy when your code wasn't that dynamic in the first place. > If TypeScript advertises a feature, shouldn't that feature, like, actually work? Fair point. I honestly don't know what a codebase that doesn't really benefits from TS looks like, but from your description I can see that their claims are a bit too much. I consider TS as part of a campaign from Microsoft trying to regain mindshare and/or control of developers, and thus always took their claims with a grain of salt.
- Spivak 5y ago
  This seems like such an odd complaint because TS is very loudly purposely unsound. So much of TS is purposely unsound. Like unless you turn on an option disabling it function parameters are contravariant! If you write a function that takes a Dog you can pass an Animal and it will type check!
  - ragnese 5y ago
    It can be as loud and purposely unsound as it wants. That won't stop me from thinking it's a bad tool. The problem is that function parameter variance is still wrong, even with all the strict flags. You just have to wrap the Dog/Animal in an Array or object. Pass in an { pet: Dog } to a function that accepts a { pet: Animal }, and the function can replace your Dog with a Cat, and TypeScript is perfectly happy to let you call `o.pet.bark()` afterwards.
    - Spivak 5y ago
      Like I get you but I genuinely can not thing of a single time I’ve ever hit this problem organically. I can’t even think of a time I’ve ever even though to modify a parameter when writing JS. I think if the language made every type immutable when passed to a function I wouldn’t even notice. It’s not an excuse because where possible I think TS should be stricter but I don’t think stuff like this really gets in the way of it providing me value when writing code.
- nawgz 5y ago
  Your experience couldn't differ more from mine. I wonder, do you think there are bad parts of Java that if you bought into them you would hate Java and your time with it for? To me, each of your examples of brokenness is completely outside the day-to-day which I work in (and honestly my comprehension vis a vis why you would use them), so I can't speak too much to them, but as someone who has gone from untyped JS (obviously) to strictly typing each key of each property in my program, I am finding it pretty funny to see you conclude > TypeScript is actually so bad that it might have honestly made JavaScript worse I couldn't disagree more. The quality of the programming, the ability to share the mental model more easily with others, the developer experience of autocomplete and declaration files; each of these things is an order of magnitude improved, and the emergent efficiency of individuals and teams follows suit.
  - ragnese 5y ago
    > Your experience couldn't differ more from mine. I wonder, do you think there are bad parts of Java that if you bought into them you would hate Java and your time with it for? Well, I literally said that I shit on Java all the time, so yeah... I hate most of Java, and my blood pressure goes up just thinking about the shitty null handling, lack of any concept of immutability, weak as hell type system, and the nightmarish combination of commonplace runtime reflection paired with type-erased generics. > To me, each of your examples of brokenness is completely outside the day-to-day which I work in (and honestly my comprehension vis a vis why you would use them), so I can't speak too much to them, but as someone who has gone from untyped JS (obviously) to strictly typing each key of each property in my program, I am finding it pretty funny to see you conclude It's not outside my day-to-day. I'm complaining because I'm being bitten by TypeScript's brokenness all the time. If you try to use the advanced TypeScript features, you'll hit all manner of inconsistencies and brokenness, too. I'm sure of it. And if you're only using the very simple typing, are you really doing anything that JSDoc wouldn't do for you? I'm fairly convinced (and I don't mean this in a condescending way) that the main group of devs that really likes TypeScript must have done mostly JavaScript and/or Python before. Because I can't imagine that someone who has spent a couple of years doing C# or C++ or Rust or Swift or even Go would be comfortable with all of the holes in TypeScript's type system.
- cdelsolar 5y ago
  um, no. TypeScript is fantastic.
- AlabasterAxe 5y ago
  What's an example of a language that you like?
  - ragnese 5y ago
    I don't know how to say this politely, but I'm afraid to answer this question because I suspect that it will just turn into either a language war or an argument along the lines of "Touché! I can point out a flaw in your favorite language, so obviously TypeScript and LanguageX are exactly equal and you're not allowed to criticize TypeScript!"
- jeswin 5y ago
  Then you don't understand the purpose of TypesScript - which is to retain JS syntax while grabbing the lower hanging benefits of a type system. There are many tools to catch errors (for example, unit tests), and the type system is just one of those tools. The proof is in the pudding. I've been writing JS (and a bunch of statically typed languages) for over twenty years. Large JS codebases have become possible now thanks to TypeScript (an example is VSCode). If you look at any large JS ecosystem project today, chances are that it's written in TypeScript rather than in vanilla JS. People are adopting it because they see benefits. If you've used TypeScript over the years, you'll also see that many major releases catch a set of new bugs in "strict" mode (which used to successfully compile earlier). That's the team fixing some of the issues you mentioned.
  - ragnese 5y ago
    > Then you don't understand the purpose of TypesScript - which is to retain JS syntax while grabbing the lower hanging benefits of a type system. There are many tools to catch errors (for example, unit tests), and the type system is just one of those tools. I understand the point. I just don't think it's a good point. If you tell me that I have a type system, then I'd expect that I could actually lean on it to catch type errors, and I'd expect it's own language features (like `readonly`) to actually do what they claim they do. I would NOT expect someone to add `readonly` to their language, but have it not actually make something a `readonly` type. > The proof is in the pudding. I've been writing JS (and a bunch of statically typed languages) for over twenty years. Large JS codebases have become possible now thanks to TypeScript (an example is VSCode). If you look at any large JS ecosystem project today, chances are that it's written in TypeScript rather than in vanilla JS. People are adopting it because they see benefits. I don't buy the argument that something being popular means it's actually good. There's a lot of group-think that goes into things being adopted. Not to mention that it's a Microsoft product and they have zillions of dollars to make sure the editor tools are good, lots of popular JS libraries get TypeScript types added on top, and just plain old PR advertising. And yes, the ability to gradually switch from JS to TS makes TS an easier choice for people who are already working with JS or who are used to JS. But, that doesn't mean that Flow, Elm, ReasonML, ReScript, ClojureScript, PureScript, etc, aren't actually better tools with bigger benefits. It just means that TS got the critical mass mindshare amongst JS devs, and now has the advantage of "everyone else is writing libraries for TS, so if I pick Flow for my project, I won't have as big an ecosystem to pull from."
- zentropia 5y ago
  I have worked with java in the past and I work with Typescript now. My experience is in reverse. Typescript system it's limited because it has to be compatible with javacript, but working with Algebraic data types is a joy. Instead java is verbose and cumbersome.
kvathupo 5y ago
You can't create lock-free data structures in Javascript (as of this comment), but you can do so in Java.
- Sinidir 5y ago
  Javascript is singlethreaded. No locks and therefore no lockfree datastructures necessary. Even webworkers are only communicated with via copying messages.
  - 5e92cb50239222b 5y ago
    Javascript is singlethreaded … which is why the root comment looks like pure trolling.
nayuki 5y ago
JavaScript is most definitely not as fast as Java. Try doing some CPU- and memory-intensive Project Euler problems in both languages and you'll see a several times difference. Java has a much better standard library - abstract data type interfaces, common and fast data structures, I/O facilities, concurrency, and more.
- romero-jk 5y ago
  True but for a dynamic lang is very close[0] and if your application lives in the Java collection framework(most do) instead of using arrays the performance is even closer. [0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
tyingq 5y ago
>Javascript being fast as Java Perhaps for some specific use cases, but certainly not for others. I also suspect moving from a fairly broad "stdlib" and somewhat curated 3rd party packages to the wild west of npm might be a barrier for many.
kaba0 5y ago
Well, let’s just add that TruffleJS, a js implementation in java which is part of the Graal project (which is a java interpreter written in java, running on top of java) can achieve comparable speeds to V8 for long running tasks (java’s JIT compilers “turn on” later than js’s because one has to be quite fast as soon as possible while the other has to be really fast but can warm up a bit more). There is a slight trick here, because this java interpreter uses a few special JIT optimizations, but it is still 100% java code (and the clever reuse of the engineering marvel what the JVM is). (Also, do check out the Graal project, its AOT compilation may be the least interesting part! It can even inline python code into js and optimize them together!) Also, Java will soon get virtual threads that will automagically become non-blocking, even if they are written with blocking code (similarly to go). Currently in incubator mode is the Vector API which let’s people write really low level SIMD code that can cleverly query the processors capabilities and will even safely fallback to for loops on ineligible CPUs. FFI will greatly improve also with project Panama, so libs like tensorflow can get better integration into the JVM. And last but not least, Valhalla is coming with value types. Yeah, it won’t happen for a few years still, but once it does, there will hardly be a platform as performant as the JVM. So, while we have heard it plenty of times how java will soon die, I think it’s future is brighter than ever.
5e92cb50239222b 5y ago
In the world of multicore processors, when "Moore's law" has been dead for a decade? Rather, the future of JS outside of browsers doesn't like very bright to me.

Javascript being fast as Java and coupled with Typescript the future of Java doesn't look very bright.

by ithrow 5y ago

Javascript being fast as Java and coupled with Typescript the future of Java doesn't look very bright.

Please stop. These kind of remarks just brings the worst of out community. JAVA is and will be fine. It's doing better than ever.

ragnese 5y ago

TypeScript is awful. Like, I shit on Java all the time, and I WAY rather work in Java than TypeScript. TypeScript's type system is so utterly broken that I honestly don't know if my code is ANY more robust than if I had written it in JavaScript. Record<> is broken/unsound: https://github.com/microsoft/TypeScript/issues/45335 https://github.com/microsoft/TypeScript/issues/45335 Generics are wonky and sometimes wrong: https://github.com/microsoft/TypeScript/issues/31006 https://github.com/microsoft/TypeScript/issues/31006 The `readonly` keyword does absolutely nothing: https://github.com/microsoft/TypeScript/issues/13347 https://github.com/microsoft/TypeScript/issues/13347 Arrays are covariant in their type param, so I can pass a `Dog[]` into a function that accepts `Animal[]`. If that function adds a `Cat` to the passed array, the compiler is perfectly happy, but we'll see a runtime error. TypeScript is actually so bad that it might have honestly made JavaScript worse, if that's even possible.

deleted 5y ago
[deleted]
Scarbutt 5y ago
It's a shame that something like Typescript is and will dominate the static typing JS ecosystem/industry instead of something simpler and sane like Rescript.
- ronenlh 5y ago
  Rescript is sane but I wouldn’t all it simpler. It can be really hard to do trivial stuff with it. I felt I had to study OCaml to understand it.
  - quaunaut 5y ago
    I think it gets pretty close, but admittedly its handling of unknown objects is just downright bad. Also, somehow, the tooling for it has one of the best features around(compiling to readable JS), but all other tooling is completely absent, and frankly, bad.
quaunaut 5y ago
I generally agree with everything you're saying, after extensive use of Typescript. Its safety guarantees usually only help within extremely tight bounds, and there's surprisingly little that it catches that couldn't be inferred directly. However, a question: > Arrays are covariant in their type param, so I can pass a `Dog[]` into a function that accepts `Animal[]`. If that function adds a `Cat` to the passed array, the compiler is perfectly happy, but we'll see a runtime error. I don't think this one is true anymore, assuming you type it correctly. I've provided an example[1]. --- Separately however, I think it's worth noting that I've been playing with the idea of doing a project in plain Javascript again, to see if I feel any serious productivity losses. - [1]: https://www.typescriptlang.org/play?#code/C4TwDgpgBAwghsKBeKBvAUFKpIC4oDk8wBANJlAK4DOE1AMgJbDAQBOARgPYAe+3XADYQ4AO3QBfdOhzQAIlwDmyNBVn4CCxWQoALLjQgc2XANYRR+YG0oRJ02VACCoxgFs4glVqgAfWAjSAPQAVCGYIVAAKrqM1FBcotBsEMCUbKLxYlAABi7ungDaALo52OAQAHQRQegAxonUiHAAJi3UxACSogBm7CktKgAUYgWC1Pj5HoIlAJTIAHyqWKPT1JVgNLpDqOqExGRUtAzMrJy8VjYQErMUKWkZUKue1Pah4VCRMXEJSVD36UyUAA7roEBAAG7scqQKAgAxQRRwKFQZikJ7xQSJZRweLMKAQHisUTtXJTTw5SrOeLwyhQOrZWgQdH4-pcNjxYBgxD41qkhmIDgQBmGVGICGMITgzm6aANTLWOCMUSILg9J5QaiUDiyaqfWryppPNodBAAUSJFlJKAAPFECZaSfFyYIFiNXGt8FE5otlk8PS8NlsdnsiAhDoYTix2Nw+Ngrjc7qlAf6xq8pPVGogWkoJlAtCUVIVdhUNFpDvpDMYzBZLrYJMVMwqoD0uFwVHzTcBun02AMhjnFNRbobBXA2B2TcQLcT2gPc7cgA https://www.typescriptlang.org/play?#code/C4TwDgpgBAwghsKBeK...
- ragnese 5y ago
  > I don't think this one is true anymore, assuming you type it correctly. I've provided an example[1]. You are correct that using a generic does fix the issue. But you called that "correct". But why, as a code author, should it be my responsibility to understand type theory better than my compiler? Because, according to basic type theory (to the extend that I understand it), TypeScript is allowing an operation that is literally incorrect in the first example. (mutable) Array types must be invariant in the type parameter. It should bitch at us for both examples. And this won't happen with just arrays. It'll happen if you do the same thing with an object with a field. E.g., instead of `Animal[]`, we could have the function take a `{ pet: Animal }`, and pass it a `{ pet: Dog }`, and replace the Dog with a Cat, causing a runtime error for the poor schmoe who thought he still had a Dog.
phailhaus 5y ago
Wild how people can have such different experiences. Typescript is hands-down one of my favorite languages, and I would choose its structural type system over Java's any day. I also use Python at work, and it's like night and day in terms of quality. Every day I have to deal with fundamentally unresolvable issues due to Python's half-baked type hints, when I could be writing much more stable, functional, and maintainable Typescript. Calling it "broken" is complete hyperbole, and no, it's not "worse than Javascript". There's a reason why the entire ecosystem is switching to Typescript, and that's because it is extremely effective at helping teams manage complex stateful applications.
- FpUser 5y ago
  >"Calling it "broken" is complete hyperbole" Well, when comparing it with strongly typed languages it does look broken for sure.
  - masak 5y ago
    This reply is a good example of how "strongly typed" ends up meaning practically nothing -- except possibly "the kind of type system I prefer". I once attended a talk where the speaker had identified half a dozen axes that papers or projects were calling "strong"/"weak" with relation to type systems. Some were not even consistent with themselves, switching definitions halfway. Type systems are tools, whose formal properties can be described and analyzed in precise detail. Unfortunately, that kind of precision is hard, so semantically empty words like "strong" get used a lot instead. This message is intended to raise awareness about that fact.
    - FpUser 5y ago
      Well one can analyze that type systems are till the hell freezes over. I personally do not care as this precise knowledge (assuming it is formalized and exists) is of zero value to me. When I want to walk I just do. I do not dwell on the details of the walking process. Anyways most likely you do know well what I meant. JS vs C++ for example.
brundolf 5y ago
It has holes, mainly because it has to be able to cover existing JavaScript codebases, which for many reasons can be an order of magnitude harder to type than code that's written from the beginning to be statically typed. The biggest holes can be filled via compiler options, and most of the rest can be papered over with the right coding practices (use Maps instead of Records, lint against `any` and type-casting, etc). I haven't encountered the situation you described, but you could probably solve it by making the function generic over TArray extends Animal[]. The rest of what you've said doesn't line up with my experience. TypeScript is an imperfect tool that requires some elbow-grease to fully benefit from. I would prefer a typed language that didn't have to work under its real-world constraints (but not Java, because of null-checking at the very least), but over the years it's caught more bugs for me than I could possibly hope to count.
- ragnese 5y ago
  Many of the worst holes are indeed because of JavaScript compat. But, not all of them. See some of my other comments in this thread. There's no earthly reason that a `type` should automatically implement Record<string, unknown> and an `interface` shouldn't. That's just dumb and annoying- not necessarily "wrong". However, it's definitely wrong to allow me to pass `const o = {}` into a function that wants `Record<string, string>`. How in the world does TypeScript (with the strict flag set!) think that an empty object is able to return a string value for any arbitrary string key? That's absurd. The issue I raised about arrays isn't just arrays, actually. It happens with object fields as well. See https://www.typescriptlang.org/play?#code/MYGwhgzhAECCB2BLAtmE0DeBfAsAKFEhgGEwAXaAUwA8zL4ATGBFNTfaT6ZSgewHcAFAEoAXNABuvRA3Z4uC6MF7wIvEJQB0IXgHNBAIh4CDwjl1x5LhKNAAieqrXpM4SVOgznOAIzAAnAGsRcSkZOUUuZVV1LR19Az8g029oS0t8RHg6fwAzMGBKaAAJSAAFSgoveS4AB0rxFg98DLwsnPzCksgHXQi6hvs9Fvx8XIBXeGAyRBVuMCRa8fA6CrJBXnFSiDXhfs5eTXqKAF5oeEp+aFJ1sytRghUICk3uiF7oM+qFY-ELq96IhGeHwqEWy3IlDWGzu+EOx00SWCewA9CilLxkLVEBp-NBEDB6nlKNMQABPaAACzAtVqZIAhEA https://www.typescriptlang.org/play?#code/MYGwhgzhAECCB2BLAt... And, the `readonly` keyword has nothing at all to do with JavaScript. Yet, they added this keyword that is completely and utterly useless. To the point that I actually introduced a bug in my own code because I put `readonly` and `Readonly<>` everywhere and expected it to actually help me. It did help me... most of the time. And then it didn't. Because it turns out that you can always take a Readonly value, assign it to a non-Readonly variable and then just mutate the hell out of it, and the compiler won't even bat an eye: https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgJIFt0FcxwEYA2EAYgPanIDeAsAFDIPJQRwAmpIBAnsjOQFzIQWdHmh0AvnTqhIsRCgCyOfETIUa9Rn1KDho8bSm06MLCARhgHZAAs4IVmvIAKHYIzZchEuQCUggBupMCsVHSMyAgcAM5gyKRgttDqgsrezhQAvLzkEYyJyVDqAHQ6yDkAtACMktK00SBxubpomCo+6hXhWgzuyLVG9Y0xpEQlBKQA5m7kZf509o6Zs6R+dCNjEBPTq-NrQA https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgA... That's just... so bad. I don't even know what else to say. Sure, it caught some of my mistakes, but if it won't even catch all of the class of errors that it's supposed to, then I have to basically be just as careful as if I didn't use the feature at all. So, it's not reducing my mental burden at all. If anything, it's just giving us/me a false sense of security and tricking me into thinking that I DON'T need to be as careful.
skitter 5y ago
> Arrays are covariant in their type param, so I can pass a `Dog[]` into a function that accepts `Animal[]`. If that function adds a `Cat` to the passed array, the compiler is perfectly happy, but we'll see a runtime error. The same is true for Java arrays. I thought the Liskov substitution principle was tautological when I first heard about it, but it seems like the original designers of Java disagree. Another example (albeit from the standart library, not the typesystem itself) is that if you try to modify a `List` or similar collection, it may throw an `UnsupportedOperationException` because it's immutable - instead of having a superinterface with only non-mutating methods and only implementing that.
- qsort 5y ago
  > The same is true for Java arrays. This is an unfortunate relic of pre-1.5 Java. The rest of the Collection API types correctly. A type-safe generic alternative is Arrays::setAll. > if you try to modify a `List` or similar collection, it may throw an `UnsupportedOperationException` Again, an historical artifact. `List` is from Java 1.2, you would effectively have to deprecate List<T> for that to work.
  - bobthebuilders 5y ago
    Most of these things in TS are due to historical artifacts too. Namely code patterns that would not work well without them.
- ragnese 5y ago
  Ugh. You're going to make me defend Java? I'm going to need a drink... First point: Yes, Java's arrays are broken and it offends me greatly. However, in practice, it's much more common to use Lists, which are not broken. In JavaScript/TypeScript "Array" is the equivalent of Java's List, so if you want a dynamically sized, contiguous, collection, you are stuck with the broken thing. Then, the other issue is that, despite my comment's wording, this problem isn't ONLY present in Arrays. It's also a problem with objects, and (I assume) every other non-primitive type. See here: https://www.typescriptlang.org/play?#code/MYGwhgzhAECCB2BLAtmE0DeBfAsAKFEhgGEwAXaAUwA8zL4ATGBFNTfaT6ZSgewHcAFAEoAXNABuvRA3Z4uC6MF7wIvEJQB0IXgHNBAIh4CDwjl1x5LhKNAAieqrXpM4SVOgznOAIzAAnAGsRcSkZOUUuZVV1LR19Az8g029oS0t8RHg6fwAzMGBKaAAJSAAFSgoveS4AB0rxFg98DLwsnPzCksgHXQi6hvs9Fvx8XIBXeGAyRBVuMCRa8fA6CrJBXnFSiDXhfs5eTXqKAF5oeEp+aFJ1sytRghUICk3uiF7oM+qFY-ELq96IhGeHwqEWy3IlDWGzu+EOx00SWCewA9CilLxkLVEBp-NBEDB6nlKNMQABPaAACzAtVqZIAhEA https://www.typescriptlang.org/play?#code/MYGwhgzhAECCB2BLAt... So even a basic object field is broken in TypeScript's type system. What the hell are we supposed to do with this? I do have thoughts and opinions about Java's Collection interfaces, the immutable implementations, etc, but that feels like a whole other topic.
Zababa 5y ago
> TypeScript's type system is so utterly broken that I honestly don't know if my code is ANY more robust than if I had written it in JavaScript. You gave three examples that seem relatively rare. At work we use TypeScript to type a codebase that was mostly plain JavaScript, and we write TypeScript as plain JavaScript. It does very well its job of offering use better tooling and compile-time guarantees. If you consider it as a way to statically-type existing JS codebases, it's good. If you consider it as a language on its own, it's not great.
- ragnese 5y ago
  I only gave three examples because it was a single Hacker News comment and I didn't think I should keep a running catalog of every single hole/issue/inconsistency that I've encountered in the last year of working on a TypeScript project. I gave a few more examples in other comments in this thread. I can go look at the code comments I wrote in my project and come up with a longer list for you if you like. > You gave three examples that seem relatively rare. At work we use TypeScript to type a codebase that was mostly plain JavaScript, and we write TypeScript as plain JavaScript. It does very well its job of offering use better tooling and compile-time guarantees. If you consider it as a way to statically-type existing JS codebases, it's good. If you consider it as a language on its own, it's not great. This is a legitimately genuine question: if you're treating TypeScript as just type annotations on an otherwise regular-old-JavaScript codebase, then why are you using TypeScript rather than just JavaScript with JSDoc comments? Also, I can't quite tell. Are you defending TypeScript's brokenness by suggesting we just don't use all of its advertised features? Isn't that... kind of weak? It's like the joke about going to the doctor: "Doctor, my elbow hurts when I do this." "Well, don't do that!" -- If TypeScript advertises a feature, shouldn't that feature, like, actually work?
  - Zababa 5y ago
    > This is a legitimately genuine question: if you're treating TypeScript as just type annotations on an otherwise regular-old-JavaScript codebase, then why are you using TypeScript rather than just JavaScript with JSDoc comments? TypeScript is way easier to write, and allows to anotate more stuff. We do have some JS that will stays as JS that's anotated with JSDoc, and it's a worse experience than TS. > Also, I can't quite tell. Are you defending TypeScript's brokenness by suggesting we just don't use all of its advertised features? I'm defending the usefulness of the tool, but not its marketing. I think the approach of trying to cover every single usage of JS is not the best, and leads to some complex features and weird edge cases like the ones you mentionned. But for typing plain JS, it works very well. I guess we get a lot of value from TS because static typing is easy when your code wasn't that dynamic in the first place. > If TypeScript advertises a feature, shouldn't that feature, like, actually work? Fair point. I honestly don't know what a codebase that doesn't really benefits from TS looks like, but from your description I can see that their claims are a bit too much. I consider TS as part of a campaign from Microsoft trying to regain mindshare and/or control of developers, and thus always took their claims with a grain of salt.
Spivak 5y ago
This seems like such an odd complaint because TS is very loudly purposely unsound. So much of TS is purposely unsound. Like unless you turn on an option disabling it function parameters are contravariant! If you write a function that takes a Dog you can pass an Animal and it will type check!
- ragnese 5y ago
  It can be as loud and purposely unsound as it wants. That won't stop me from thinking it's a bad tool. The problem is that function parameter variance is still wrong, even with all the strict flags. You just have to wrap the Dog/Animal in an Array or object. Pass in an { pet: Dog } to a function that accepts a { pet: Animal }, and the function can replace your Dog with a Cat, and TypeScript is perfectly happy to let you call `o.pet.bark()` afterwards.
  - Spivak 5y ago
    Like I get you but I genuinely can not thing of a single time I’ve ever hit this problem organically. I can’t even think of a time I’ve ever even though to modify a parameter when writing JS. I think if the language made every type immutable when passed to a function I wouldn’t even notice. It’s not an excuse because where possible I think TS should be stricter but I don’t think stuff like this really gets in the way of it providing me value when writing code.
nawgz 5y ago
Your experience couldn't differ more from mine. I wonder, do you think there are bad parts of Java that if you bought into them you would hate Java and your time with it for? To me, each of your examples of brokenness is completely outside the day-to-day which I work in (and honestly my comprehension vis a vis why you would use them), so I can't speak too much to them, but as someone who has gone from untyped JS (obviously) to strictly typing each key of each property in my program, I am finding it pretty funny to see you conclude > TypeScript is actually so bad that it might have honestly made JavaScript worse I couldn't disagree more. The quality of the programming, the ability to share the mental model more easily with others, the developer experience of autocomplete and declaration files; each of these things is an order of magnitude improved, and the emergent efficiency of individuals and teams follows suit.
- ragnese 5y ago
  > Your experience couldn't differ more from mine. I wonder, do you think there are bad parts of Java that if you bought into them you would hate Java and your time with it for? Well, I literally said that I shit on Java all the time, so yeah... I hate most of Java, and my blood pressure goes up just thinking about the shitty null handling, lack of any concept of immutability, weak as hell type system, and the nightmarish combination of commonplace runtime reflection paired with type-erased generics. > To me, each of your examples of brokenness is completely outside the day-to-day which I work in (and honestly my comprehension vis a vis why you would use them), so I can't speak too much to them, but as someone who has gone from untyped JS (obviously) to strictly typing each key of each property in my program, I am finding it pretty funny to see you conclude It's not outside my day-to-day. I'm complaining because I'm being bitten by TypeScript's brokenness all the time. If you try to use the advanced TypeScript features, you'll hit all manner of inconsistencies and brokenness, too. I'm sure of it. And if you're only using the very simple typing, are you really doing anything that JSDoc wouldn't do for you? I'm fairly convinced (and I don't mean this in a condescending way) that the main group of devs that really likes TypeScript must have done mostly JavaScript and/or Python before. Because I can't imagine that someone who has spent a couple of years doing C# or C++ or Rust or Swift or even Go would be comfortable with all of the holes in TypeScript's type system.
cdelsolar 5y ago
um, no. TypeScript is fantastic.
AlabasterAxe 5y ago
What's an example of a language that you like?
- ragnese 5y ago
  I don't know how to say this politely, but I'm afraid to answer this question because I suspect that it will just turn into either a language war or an argument along the lines of "Touché! I can point out a flaw in your favorite language, so obviously TypeScript and LanguageX are exactly equal and you're not allowed to criticize TypeScript!"
jeswin 5y ago
Then you don't understand the purpose of TypesScript - which is to retain JS syntax while grabbing the lower hanging benefits of a type system. There are many tools to catch errors (for example, unit tests), and the type system is just one of those tools. The proof is in the pudding. I've been writing JS (and a bunch of statically typed languages) for over twenty years. Large JS codebases have become possible now thanks to TypeScript (an example is VSCode). If you look at any large JS ecosystem project today, chances are that it's written in TypeScript rather than in vanilla JS. People are adopting it because they see benefits. If you've used TypeScript over the years, you'll also see that many major releases catch a set of new bugs in "strict" mode (which used to successfully compile earlier). That's the team fixing some of the issues you mentioned.
- ragnese 5y ago
  > Then you don't understand the purpose of TypesScript - which is to retain JS syntax while grabbing the lower hanging benefits of a type system. There are many tools to catch errors (for example, unit tests), and the type system is just one of those tools. I understand the point. I just don't think it's a good point. If you tell me that I have a type system, then I'd expect that I could actually lean on it to catch type errors, and I'd expect it's own language features (like `readonly`) to actually do what they claim they do. I would NOT expect someone to add `readonly` to their language, but have it not actually make something a `readonly` type. > The proof is in the pudding. I've been writing JS (and a bunch of statically typed languages) for over twenty years. Large JS codebases have become possible now thanks to TypeScript (an example is VSCode). If you look at any large JS ecosystem project today, chances are that it's written in TypeScript rather than in vanilla JS. People are adopting it because they see benefits. I don't buy the argument that something being popular means it's actually good. There's a lot of group-think that goes into things being adopted. Not to mention that it's a Microsoft product and they have zillions of dollars to make sure the editor tools are good, lots of popular JS libraries get TypeScript types added on top, and just plain old PR advertising. And yes, the ability to gradually switch from JS to TS makes TS an easier choice for people who are already working with JS or who are used to JS. But, that doesn't mean that Flow, Elm, ReasonML, ReScript, ClojureScript, PureScript, etc, aren't actually better tools with bigger benefits. It just means that TS got the critical mass mindshare amongst JS devs, and now has the advantage of "everyone else is writing libraries for TS, so if I pick Flow for my project, I won't have as big an ecosystem to pull from."
zentropia 5y ago
I have worked with java in the past and I work with Typescript now. My experience is in reverse. Typescript system it's limited because it has to be compatible with javacript, but working with Algebraic data types is a joy. Instead java is verbose and cumbersome.

kvathupo 5y ago

You can't create lock-free data structures in Javascript (as of this comment), but you can do so in Java.

Sinidir 5y ago
Javascript is singlethreaded. No locks and therefore no lockfree datastructures necessary. Even webworkers are only communicated with via copying messages.
- 5e92cb50239222b 5y ago
  Javascript is singlethreaded … which is why the root comment looks like pure trolling.

nayuki 5y ago

JavaScript is most definitely not as fast as Java. Try doing some CPU- and memory-intensive Project Euler problems in both languages and you'll see a several times difference. Java has a much better standard library - abstract data type interfaces, common and fast data structures, I/O facilities, concurrency, and more.

romero-jk 5y ago
True but for a dynamic lang is very close[0] and if your application lives in the Java collection framework(most do) instead of using arrays the performance is even closer. [0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

tyingq 5y ago

>Javascript being fast as Java Perhaps for some specific use cases, but certainly not for others. I also suspect moving from a fairly broad "stdlib" and somewhat curated 3rd party packages to the wild west of npm might be a barrier for many.

kaba0 5y ago

Well, let’s just add that TruffleJS, a js implementation in java which is part of the Graal project (which is a java interpreter written in java, running on top of java) can achieve comparable speeds to V8 for long running tasks (java’s JIT compilers “turn on” later than js’s because one has to be quite fast as soon as possible while the other has to be really fast but can warm up a bit more). There is a slight trick here, because this java interpreter uses a few special JIT optimizations, but it is still 100% java code (and the clever reuse of the engineering marvel what the JVM is). (Also, do check out the Graal project, its AOT compilation may be the least interesting part! It can even inline python code into js and optimize them together!) Also, Java will soon get virtual threads that will automagically become non-blocking, even if they are written with blocking code (similarly to go). Currently in incubator mode is the Vector API which let’s people write really low level SIMD code that can cleverly query the processors capabilities and will even safely fallback to for loops on ineligible CPUs. FFI will greatly improve also with project Panama, so libs like tensorflow can get better integration into the JVM. And last but not least, Valhalla is coming with value types. Yeah, it won’t happen for a few years still, but once it does, there will hardly be a platform as performant as the JVM. So, while we have heard it plenty of times how java will soon die, I think it’s future is brighter than ever.

5e92cb50239222b 5y ago

In the world of multicore processors, when "Moore's law" has been dead for a decade? Rather, the future of JS outside of browsers doesn't like very bright to me.