3 ms·
I think the author is still forming their opinion on those languages. Several of their points sound wrong. "Dependency heavy workloads and industry trends" Th
by slver 6y ago
I think the author is still forming their opinion on those languages. Several of their points sound wrong.
"Dependency heavy workloads and industry trends"
The author complains about JS having small packages about trivial things (and for some reason when people talk about this they always mention lpad, apparently lpad is the only small package in NPM /s).
And about the fact Java has a type system. Many languages have a type system. In fact JS also has a type system through TypeScript.
"Nominal typing"
TypeScript typeguards are compared with the lack of Java typeguards.
- Java has typeguards and they're even being extended: https://openjdk.java.net/jeps/394 https://openjdk.java.net/jeps/394
- Type guards have nothing to do with nominal vs. structural typing. They're rather used to disambiguate unions. If you have no unions you need no type guards.
- Interfaces in TS are structural, but classes are nominal. Typeguards can be either.
"Removal of responsibility for optimization"
The author believes Java frees them from memory management and multithreading race conditions, and the need to optimize (like think about underlying data structures, algorithms etc.).
Java reduces memory management concern relative to C++, but you still have reference leaks, you still need to free resources like file handles, connections etc. Also Java is no different than JS, C#, Python, etc. in that regard.
Java DOES NOT prevent race conditions.
Java DOES NOT mean you don't have to optimize.
-------------
All in all this reads a bit like a JS developer who just discovered Java and is excited. That's good, but my conclusion is Java isn't underhyped. Or overhyped. It's hyped just about as much as it needs to be.
- cnity 6y ago> Interfaces in TS are structural, but classes are nominal. Typeguards can be either. Is this true? I might be missing something, but this snippet to me suggests otherwise[0]. [0]: https://www.typescriptlang.org/play?#code/MYGwhgzhAECyCeBhcVoG8CwAoa0wC5oA7AVwFsAjAUwCcBubXCwiAFxoEsiBzBrR6MAD2RNjRLBWQmgAoAlOgG5WACw4QAdGGgBeaAEYADH1zK1mirugAiABJUQIIdYEBfbO-5YAZiSKSOEWhWMABrKggEZEgIGTIkFAhCKMSFTBxBEQghECoNJ24ZAHJLdWgigBpoeOioDQo5Pk9sYVFWYiFWFJirdNwCAwqBZhsAFXNoMqJOjrIuMEd4PDgEmKqKEnaOLZgxCVYSGgWQeBcsZqwQ8MjVqBlprtuIRqA https://www.typescriptlang.org/play?#code/MYGwhgzhAECyCeBhcV...
- slver 6y agoSorry, you're right. I was thinking about "instanceof" which is a native JS feature, and it matches classes nominally.
- cnity 6y agoGot you. I was a little disappointed that TS only had structural type checking, but then it's still better than nothing.
- slver 6y agoTo be honest it makes sense for it. It means if something (a library, browser API etc.) has no type, you can write an interface for it and hint for it, without depending on anything else. You can think about the structural type as a hash check on a type. If the hash matches, chances are it's the type you want. Collisions are possible, but highly unlikely, hence why in practice it works great (and we still have instanceof and tagged types).