Java isn't worse than C++; it has a much more capable run-time, something which is left as an implementation-defined footnote in C++.

Java had a leg-up over C++ by several decades in having a concurrency story (at all) in the language.

I wouldn't use std:: anything for threads even in a greenfield C++ project today.

Garbage collection is more advanced than the primitive management tools available in C++, like smart pointers to reference counted or exclusively owned objects: those approaches are strictly worse than the correct, gold-standard solution to the object lifetime problem.

▲

da_chicken a day ago | parent | next [-]

It's hard to look at Java and not see it as a transitional language now. Electron, Node, and even .Net have fundamentally been more successful implementing ideas that first saw widespread adoption in Java. JSON is basically XML, which is what Java pushed so hard for for data exchange instead of really gross binary serialization formats.

Although, Java wasn't really trying to compete with C++ everywhere. It's just that, at the time, C++ was used at all levels. I mean, this was a time when it was C++, Visual Basic, or Turbo Pascal/Delphi for application programming. You couldn't easily get more abstract than that. That's wildly unlike today's landscape.

▲

zahlman a day ago | parent [-]

> JSON is basically XML, which is what Java pushed so hard for for data exchange instead of really gross binary serialization formats.

JSON over XML is more of a "better is better" case, though.

	▲	da_chicken 20 hours ago \| parent \| next [-]
		If XML dropped attributes and required everything to be an element -- which people always want to object to because they've used XML wrong their entire careers, but that's exactly what JSON did -- if they did that, and then also permitted `</>` as a universal close tag so that nesting isn't really a problem... which, again, is exactly what JSON did (and SGML)... then I think XML would not be so maligned. Like the problem with XML isn't that it wasn't capable. It's that it had too many features that actually aren't useful, and features that are distracting to the point of making people use it wrong. Because almost the entirety of the remaining JSON ecosystem is just duplicating what XML did. We have JSON Path and JSON Query. We have JSON schema. There's even JSLT, although it didn't inherit the flaws of that XSLT library. About the only thing there still seems to be an argument about that XML did is JSON comments. And, to be clear, JSON's perception as being better performing primarily comes from the fact that web browser developers had a vested interest in making JavaScript engines high performance for ordinary JavaScript, and they spent more effort on that than on their XML libraries simply because it was more important. That means the problem with the web hasn't been the use of XML. It's been the way we stapled half a dozen languages together to do one thing: display a document as a computer interface. But if you use XML to the minimal level as JSON requires by it's nature, and if XML had gotten the performance interest that JavaScript did, then XML would be fine. So I don't think JSON is better than XML. I think JSON just got lucky.
	▲	kstrauser a day ago \| parent \| prev [-]
		I couldn't possibly agree more. I remember the first time I saw JSON over HTTP. Within a week, I started ripping out all the SOAP code I'd written because "that's what you're supposed to use". JSON plus a few standard verbs is better than the old XML web services in every way.

▲

eikenberry a day ago | parent | prev | next [-]

> Java isn't worse than C++;

"Worse is better" is about simplicity vs expressibility tradeoffs, not an absolute better/worse value judgement. By saying Java is worse than C++ here the OP is only saying that Java is simpler (less expressible) than C++.

▲

kazinator a day ago | parent [-]

Nope; worse is better is about simplicity versus correctness tradeoffs. I've read the P. Gabriel essay enough times that I can rely on my memory of it.

Like whether to hide interrupted system calls, or punt the responsibility for restarting them to the application. (That "PC loser-ing problem" example used in the essay).

Between C++ and Java, it is hard call, but I would say that the Java ecosystem values correctness more than C++.

I don't mean valuing the correctness of a delivered application, but valuing the contribution of the language stack to that goal.

Java manages memory, and defines the order of evaluation of operands in an expression. Need we go on? Java also has a security story for loading compiled code. There is no sandbox model of any kind in C++.

	▲	eikenberry 7 hours ago \| parent [-]
		This is of course Correct (pun intended)... but IMO the underlying meaning of correctness was a correctness of the abstractions to the problem domain and that correctness ultimately boils down to the expressibility of the language that allows it to create the correct abstractions. This interpretation might have to do with my having known many fans of Lisp (of which I'm one) and that people who love Lisp (like the author of the paper) are usually big expressibility proponents.

▲

ajross a day ago | parent | prev [-]

> Java had a leg-up over C++ by several decades in having a concurrency story (at all) in the language.

While sort of technically true, concurrent code expressed in high level language was almost invented in C in the 1980's as the first Unix SMP devices took off (early multiprocessing work at the OS level was at the assembly level, Unix was almost alone in having a portable kernel and the need for SMP).

Java, coming along about a decade later from the same incubation environment, very much reflects that learning. But no, they did it right in Java because they had already done it in C.