2 ms·

I was working in C++ when Java came out, and I remember my initial reactions: 1. Nice language, a relief after the complexity of C++, which was a complicated m

I was working in C++ when Java came out, and I remember my initial reactions: 1. Nice language, a relief after the complexity of C++, which was a complicated mess even in the early 90s. 2. GC! A great relief. 3. Completely bizarre memory model, due to the inability to physically embed one object inside another. 25 years later: Language: My view of the language itself is lower than it used to be. This is not due to the current "objects are evil" fad, not due to the preposterous AbstractFactoryManagerFactory abstractions that are sometimes enforced, and not due getters/setters (don't use them if you don't want to, I don't). No, I think there are two basic problems with the language itself. First, type erasure is just bad. It does simplify a number of things for implementation, but it leads to non-intuitive hacks required to get things right. Second, they got closures all wrong, basically limited to constant values so that the implementation can rely on copying. So many other languages get it right. (Have they fixed this? I haven't been an active Java user for a few years.) GC: Still nice, but: GC performance is still an issue. This is undeniable -- Oracle is still experimenting with new GCs. Tuning is getting so arcane, that I think I might actually prefer the C model. Valgrind was not available when I was an active C++ developer. It makes C memory debugging so simple, and GC tuning is such a mess, that my preference for GC (at least in Java) has diminished. If I had to rank memory management models, I think I'd go with 1) C + valgrind, 2) GC, and a very distant 3) Swift-style reference counting. Memory model: The lack of physically embedded objects is still a miserable choice. I understand why they did it -- it makes object identity much more complicated. But it really does rob Java of some critical tools for improving performance. Project Valhalla (value types) seems to be perpetually several releases in the future.

AtlasBarfed 6y ago
C still suffers from lack of real Unicode. One of Java's other big wins was unicode out of the box. Granted it was two-byte unicode, but still... it was aware it was a thing. I write Groovy with @CompileStatic. I do sigh when I have to "drop back" to Java. Much like Valgrind for C, IDEs helped out with Java's rough edges.
kaba0 6y ago
What’s wrong with type erasure? It’s always get brought up, but other than missing overloading (it never occured to me, but it is at least an objective criticism), it is basically what every single language does, other than c#.
- geophile 6y ago
  Type safety, overloading, doesn’t play well with arrays (T[]), and other baggage related to the lack of value types, (e.g. <Integer> is ok but not <int>). C++ also does not rely on type erasure.
  - kaba0 6y ago
    What’s up with type safety? The only escape hatch is casting (and of course co/contra/invariance, but it is a semantic issue). Overloading may be a legit issue, but I am yet to run into it, you are right about arrays and value types, but they are being worked on and hopefully project valhalla can solve these issues. C++’s templates have different trade-offs (lack of semantic validation, though perhaps it is solved by concepts and constraints? I haven’t looked into them yet)

AtlasBarfed 6y ago

C still suffers from lack of real Unicode. One of Java's other big wins was unicode out of the box. Granted it was two-byte unicode, but still... it was aware it was a thing. I write Groovy with @CompileStatic. I do sigh when I have to "drop back" to Java. Much like Valgrind for C, IDEs helped out with Java's rough edges.

kaba0 6y ago

What’s wrong with type erasure? It’s always get brought up, but other than missing overloading (it never occured to me, but it is at least an objective criticism), it is basically what every single language does, other than c#.

geophile 6y ago
Type safety, overloading, doesn’t play well with arrays (T[]), and other baggage related to the lack of value types, (e.g. <Integer> is ok but not <int>). C++ also does not rely on type erasure.
- kaba0 6y ago
  What’s up with type safety? The only escape hatch is casting (and of course co/contra/invariance, but it is a semantic issue). Overloading may be a legit issue, but I am yet to run into it, you are right about arrays and value types, but they are being worked on and hopefully project valhalla can solve these issues. C++’s templates have different trade-offs (lack of semantic validation, though perhaps it is solved by concepts and constraints? I haven’t looked into them yet)