Live data from Hacker News

Don’t call it a comeback: Java is still champ

github.com

161–170 of 557 posts

Re: Don’t call it a comeback: Java is still champ

#161

Earlier quoted context omitted.

My problem with Java is that C# exists which does huge portions of the stuff Java excels at just… better. Before, .NET only ran on Windows which disqualified it from many serious applications server deployments. Today, this is no longer the case for everything but cross platform GUI libraries, and even those are an option if you're okay with not having Linux support. It's more akin to the old car you had just before…

What stuff does C# objectively do better than Java?

Generics, LINQ, structs, delegates, to name just four.

Re: Don’t call it a comeback: Java is still champ

#162

Earlier quoted context omitted.

I don't understand the part about go, does that mean go doesn't require async but gives you the functionality of async? (I never tried go) The problem with async is that we can separate when to start a task and when to ask for its result. The compiler can just add await everywhere an async function is called, it is trivial, but you don't get the flexibility of async. If everything is treated as async, you will need t…

> If everything is treated as async, you will need to await everything In go you work rather differently. You let tasks go off and do their thing, and provide a channel to communicate. Pulling a response from the channel is the 'await'. A good part of go's magic is that these tasks - goroutines - don't result in large amount of blocked threads. Java will soon have the building blocks of something rather similar to go…

OK I see, but I think these two approaches address different problems? The approach used by go is more powerful than async but also more verbose. The implementation is also different, async can be implemented with a generator but goroutine can't.

Re: Don’t call it a comeback: Java is still champ

#163
post #5

Java's adequate. It's like a Toyota Corolla (insert your boring car of choice here if you don't feel this one works for the analogy). Not the prettiest, not the fastest, not the most efficient. But it gets you from point A to point B with little fuss or muss. I totally get why companies adopt and standardize on it. Do I use it for personal projects? Nope. Because it's not fun to "drive". For that, I pick the equivale…

I wouldn’t use Java again because I am done dealing with the brokenness of Maven and Gradle. They are the opposite of “little fuss and muss.” The Go build tools fit your analogy better.

Re: Don’t call it a comeback: Java is still champ

#164
post #45

Earlier quoted context omitted.

I think people dislike XML precisely because it's so flexible and unopinionated. It means that when you're parsing a new XML source, you have to look for data that might be encoded in two or three little niches. God help you if it's encoded in each of them, and if the data therein is contradictory. Basically, it's easy to "hold it wrong" in a way that harms consumers.

> I think people dislike XML precisely because it's so flexible and unopinionated. You're probably right. > Basically, it's easy to "hold it wrong" in a way that harms consumers. I feel a bit like this could equally apply to things like GraphQL. I spend more time reading the docs on how someone's internal data model is built than I do writing GraphQL queries. And if I get that data model slightly wrong, my query's ga…

Every "contract" language (e.g. .graphql) I've used so far has it's ups and downs.

One that keeps biting us in GQL, for instance, is that it won't let you define a union type for mutation inputs, so you end up needing N methods like `GetByX(X)`, `GetByY(Y)`, `...` instead of a single `Get(X|Y|...)`. Not to mention support for versioning message types, etc...

FWIW: I think proto3 is probably the best I've used, at length and in production. Granted it has its "warts", but the idioms to circumvent them are fairly well-documented and agreed upon, even if they're a bit "ugly" in the syntactical sense.

FWIW pt 2: Like yourself, I think, I would not consider JSON to be appropriate as a schema-defining "contract" language in 2022, for a company that plans to be around in 5 years. There are too many better options available.

Re: Don’t call it a comeback: Java is still champ

#165
post #100

Earlier quoted context omitted.

I’ve never written XML in Java in the past 7 years of being a developer.

It's not the way Java is done now because, as noted, it was awful. Java is almost 30 years old now. Developers who worked in Java 20 years ago had a pretty different experience than it is now. However, I'm sure a lot of that code still exists.

[Cries in spring config]

Re: Don’t call it a comeback: Java is still champ

#166
post #63

Earlier quoted context omitted.

> To use anything else (than JavaSE without heavy deps.) on the server is madness. That's a terribly broad generalization. There are multiple other options that are entirely sane.

What other good dynamic runtimes with widespread use like the JVM exist?

BEAM

Re: Don’t call it a comeback: Java is still champ

#167
post #5

Java's adequate. It's like a Toyota Corolla (insert your boring car of choice here if you don't feel this one works for the analogy). Not the prettiest, not the fastest, not the most efficient. But it gets you from point A to point B with little fuss or muss. I totally get why companies adopt and standardize on it. Do I use it for personal projects? Nope. Because it's not fun to "drive". For that, I pick the equivale…

My problem with Java is that C# exists which does huge portions of the stuff Java excels at just… better. Before, .NET only ran on Windows which disqualified it from many serious applications server deployments. Today, this is no longer the case for everything but cross platform GUI libraries, and even those are an option if you're okay with not having Linux support. It's more akin to the old car you had just before…

> My problem with Java is that C# exists which does huge portions of the stuff Java excels at just… better.

Might want to give some evidence of this. Also, C# has no plans of green threads. It went the async/await way which is a pain.

Re: Don’t call it a comeback: Java is still champ

#168
post #45

Earlier quoted context omitted.

Personal rant: I've never understood the hate towards XML. It's a practical and flexible markup language that does not depend on whitespace or quoting every bloody thing. Plus, every markup language invented since has had to re-invent XML things that, surprise surprise were actually needed. Paths, schemas, comments, etc. I get frustrated with JSON because of things I could do in XML that I can't do in JSON without br…

I think people dislike XML precisely because it's so flexible and unopinionated. It means that when you're parsing a new XML source, you have to look for data that might be encoded in two or three little niches. God help you if it's encoded in each of them, and if the data therein is contradictory. Basically, it's easy to "hold it wrong" in a way that harms consumers.

I think it also got horribly abused by some use cases. People tried to allow programming in it (e.g. if statements and loops) when an actual DSL would have been a better solution.

I know that was my last straw before I started assuming that anything that required XML would be painful to work with. It wasn't an entirely fair assumption, but it was correct often enough that I used it as a helpful heuristic.

Re: Don’t call it a comeback: Java is still champ

#169
post #93

Earlier quoted context omitted.

Who stopped what? Java 19 is the upcoming release.

using the parent comments naming scheme it is actually 1.19, I don’t know why they stopped developing major releases however.

1.6 and 1.8 and the like were major releases. While LTS doesn’t have a well-defined meaning for OpenJDK, in general 11+6*n are the versions that are considered LTS (due to other vendors providing paid support for those).

Let’s not read more into arbitrary version numbers.

Re: Don’t call it a comeback: Java is still champ

#170
post #2

I've ditched Spring, am using Vert.x with Java 17, reactive & functional styles, records. Seems like a completely different language. If only project Loom will get out there so I wont be coding everything like Javascript I'd be happy. :)

The time I used vert.x in my day job was by far the best Java experience in my career. Completely different language. And the vert.x maintainers have been all around great wrt to responding to issues and/or accepting contributions. Great framework. It has it's quirks and limitations but overall I absolutely loved working with it.
Post reply on HN