3 ms·

> 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

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

nawgz 5y ago
> 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 I don't think this is entirely wrong, it's exactly TypeScript's retained dynamic-ism that makes it familiar and "easier"; but in my case I've spent significant time writing Java, including production scheduling software, and I just fully disagree that TS is "weak as hell" and has "type-erased generics". Like I said, I find it in me to strictly type programs including the boundary-crossing data (GraphQL w/ codegen or io-ts are leaders in their respective paradigms) and including a library of generic components which correctly can give you access to any data T you passed through to implement content generators etc.. For example, there were complaints about Record<>, but I simply use the object syntax { [key: string]: number | string }, so I can't speak to your use case, but I don't really understand why Record would be used. I suppose I agree immutability doesn't exist without explicit use of Object.freeze, but I can't believe I would hear someone say "shitty null handling" as a TS/JS complaint when they come from Java land. To reduce my implementations to "JSDoc" is pretty funny as well For the example about generics, I suppose I'd have to understand why it was using `K extends keyof T` instead of `K in keyof T`, I would agree the "extends" keyword is horrible for generics but I also find it difficult to conceptualize why someone would care about the keys in the superset that aren't in the default set (i.e. K extends keyof T - K in keyof T seems like a useless set to me) To conclude, I guess I would love to see you show me what you are using "advanced TypeScript features" for, because I write fairly complex dataflow / model / graph editors & capabilities, and go to lengths to provide the capabilities generically as a component library, and I've never found an issue providing type hints. Period. I of course haven't implemented everything ever though, and I do avoid doing too much in the world of union types, so maybe this is why

nawgz 5y ago

> 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 I don't think this is entirely wrong, it's exactly TypeScript's retained dynamic-ism that makes it familiar and "easier"; but in my case I've spent significant time writing Java, including production scheduling software, and I just fully disagree that TS is "weak as hell" and has "type-erased generics". Like I said, I find it in me to strictly type programs including the boundary-crossing data (GraphQL w/ codegen or io-ts are leaders in their respective paradigms) and including a library of generic components which correctly can give you access to any data T you passed through to implement content generators etc.. For example, there were complaints about Record<>, but I simply use the object syntax { [key: string]: number | string }, so I can't speak to your use case, but I don't really understand why Record would be used. I suppose I agree immutability doesn't exist without explicit use of Object.freeze, but I can't believe I would hear someone say "shitty null handling" as a TS/JS complaint when they come from Java land. To reduce my implementations to "JSDoc" is pretty funny as well For the example about generics, I suppose I'd have to understand why it was using `K extends keyof T` instead of `K in keyof T`, I would agree the "extends" keyword is horrible for generics but I also find it difficult to conceptualize why someone would care about the keys in the superset that aren't in the default set (i.e. K extends keyof T - K in keyof T seems like a useless set to me) To conclude, I guess I would love to see you show me what you are using "advanced TypeScript features" for, because I write fairly complex dataflow / model / graph editors & capabilities, and go to lengths to provide the capabilities generically as a component library, and I've never found an issue providing type hints. Period. I of course haven't implemented everything ever though, and I do avoid doing too much in the world of union types, so maybe this is why