> of Java is how verbose and full of boilerplate it is.

yes, new SimpleLang can have lessons learned during last 20 years implemented, as in example from another commenter: https://news.ycombinator.com/item?id=37068380

Currently, for a given task, Java usually have 5 legacy deprecated ways to solve, and two more in newish Java versions, and dev needs to keep all of them in memory to be able to read and understand other's code.

> As for there now being multiple ways to write the same thing, this seems like something that could be easily linted into consistency.

that's if you don't work with any legacy systems and 3p libraries and never switch projects/jobs

Sounds like Kotlin is exactly such SimpleLang.

Ya, I'm not sure why people would use Java anymore given that the SimpleLang is pretty good.

Kotlin is even worse; it's younger than Java but also has 5 legacy ways to solve the problem and two more in the newer version, it's just that the legacy ways have been removed so any examples you find online won't work any more.

Are there any examples for this?

Kotlin sure moves faster than Java, but except for features that were experimental or unstable to begin with (coroutines, -X flags), I can't think of a case where more than 1 deprecated version exists (and the "deprecated" versions are not nearly as crufty as Java).

Those "experimental or unstable" features tend to be the advertised selling points of Kotlin. Particularly for async, the previous "experimental" APIs were the only ones available at the time and the recommended way of using Kotlin.

Kotlin is anything but simple

You way over exaggerate the number of different ways a given thing can practically be done in Java. Pattern matching for example only has the visitor pattern as a counterpart and you ain’t going around spewing visitor patterns, it not as simple.

Sure there are a few warts, e.g. arrays work a bit differently than Lists, and primitive-object discrepancy, but every language will pick up similar issues over time.

My comparison with c++ shows java is not more verbose if you take into account headers.

I think people are very aware that c++ is a lot more verbose than Java. What's the advantage of making this particular comparison?

I actually think c++ is not necessary more verbose than java as a language.

But memory management/safety, weaker IDE support and ecosystem make it less productive than Java for business dev.

Wait until you see this new, hyped language called Go! That is even more verbose than both!

I actually appreciate the simplicity of bare Java. It can be verbose on one hand but on the other there are no surprises because everything is just a method call on an object with no operator overloading etc. Seems like they're kind of ruining that with bizarre things like "obj instanceof Point(int x, int y))". That doesn't connotate at all that it's calling x() on the point to get x, it looks like a field. Compare with C# which has a ton of convenience features and syntactic sugar but it's all intuitive and self-explanatory. Really I wish Java would go away and .NET would take over but it's too entrenched.

Point is a record type here. Record types seem to be like Scala's case classes.

The distinction between fields and getters is intentionally blurred because these are immutable value classes.

Yes. Any language which requires an IDE to append get, set and toString for every damned variable is a language in trouble. Here we are at Java 21 and Java must be the only language in modern use which requires regex metacharacters to be escaped. This even after the introduction of raw string literals.

You missed out on Java’s records that solve your gripe with get/set.

Records are not the same as classes.

They are not, but if you need strictly a class for strictly storing data, records are superior in every way. Unfortunately some tools still want POJOs, but most (eg. Converting to json) do work with records.

Disagree with that, but please provide a counterpoint. I've using Java 17 for a large project and I was really excited to use records. I have not found any practical use case for them outside of one or two instances in a project with 2 years of development.

Storing data is also where I thought records would be a good use case. But in the real world data is not Point(x,y). If you have more than 3 or 4 fields in your record, that's simply not going to work. I thought the rest of the industry decided over a decade ago that using positional properties (e.g. new MyRecord(a,b,c,d,e,f,g)) to initialize an object was a bad idea. I think Rich Hickey gave a whole talk on that subject. If there's a future plan to be able to create records using named props, e.g. new MyRecord([firstName: "Bob"]), then I would reconsider my opinion.

Have you seen the whole plan? https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

Thanks for sharing. It looks interesting.