I would say Java the language is fine, but the culture around it is what's grown the distaste many have for it. The overuse of design patterns, etc.

I also find it fun how Guy Steele had in retrospect the perfect plan for Java back in the 1990s, and it took them 15 years to come around to it:

https://www.youtube.com/watch?v=_ahvzDzKdB0

> I would say Java the language is fine,

When I was using it I didn't particularly mind it except for the clumsy handling of functions (i.e. as objects instead of first-class citizens) and verbosity (no automatic accessors, implicit typing, etc). Adding Lombok solved most of these. *EDIT: Except for runtime type erasure of generics which caused (not sure about new Java) performance issues and made certain type operations difficult.

> but the culture around it is what's grown the distaste many have for it.

Having to debug esoteric issues with classpath, Spring, CDI, JPA, Aspect4j, etc. is hell on earth. I've lived that life and have no desire to do so again. Because Java is the lingua franca of enterprise development it also tends to rear its ugly head on modernization projects and rewrites. 80% of the abhorrently-engineered codebases I've encountered in my career were written in Java by body shops (C# and Coldfusion were the runners up).

> The overuse of design patterns, etc.

I'm not an adherent of the design pattern cargo cult but I'm one of four people under the age of 50 that have actually read the GoF book and I do indeed sometimes name objects after patterns described in the book; I typically design components and name them such after the fact as opposed to constructing systems from the ground up using design patterns. Calling a thing that persists comments in a database `CommentRepository` is a lot more useful than calling it `CommentHelper`.

> Having to debug esoteric issues with classpath, Spring, CDI, JPA, Aspect4j, etc. is hell on earth.

The term "DLL Hell" came from Windows development before it. The Node/Ruby/Python equivalent is getting native libraries to build (node-gyp, I'm looking at you!). I've burned days in Ruby Version Hell and Node Version Hell. Javascript dependency upgrades are a nightmare compared to Java dependency upgrades.

I don't think this problem has gone away, or even improved. It's just a grim fact of life, and Java doesn't deserve special mention.

Despite my love for the language (and Stack has mostly fixed this), I feel like Haskell's "Cabal Hell" is amongst my least-favorite headaches from my past.

Getting weird, hard to follow conflicts between different packages on Hackage and dealing with weird compiler hack flags is something that never got fun or easy.

The things you mention are no fun either (`node-gyp` in particular), but the Java issues I encountered were far beyond run-of-the-mill runtime linking and interop issues you describe. The details are lost to time and a bit fuzzy but I recall the primary issue being competing CDI implementations stepping on each other when we tried to use JSF with a recent version of Spring... and because most everything in the Java ecosystem was doing some opaque Aspect4J magic it was nigh-impossible to debug.

If you don’t like putting objects and classes on the left you can write

   import static example.Library.*;

And proceed to write in your main method

   var x = someFunction(6, ‘that’);

in a style like C, LISP, or ML. You can write a whole program (like the answer for a HackerRank problem) in a single file. The developers of Java have always respected the ML family and JDK17 incorporates pattern matching, records, algebraic types and and many other features that make functional programming fun.

The type erasure problem for generic classes goes away when you use generic methods; type inference works without limitation for generic methods and is great for defining APIs for internal domain-specific languages

   any(grammar,you.want(ifIt.parses(ON_THE_LEFT)));

the great thing about Java is a quality IDE is certain to support this programming style.

Any complaint that the internal DSL is too verbose can be attacked by the use of code generation which is straightforward to incorporate in a maven build and your IDE. (The LISPer is using code generation and you have to do it if you want to keep up.)

I think the real majority of hate that I've seen for design patterns are when juniors go into a system looking to slap a design pattern anywhere they possibly can, quickly creating a ball of mud that is difficult to work with and figure out. At least that's been my experience (and I have to sadly admit I did the same when I was a junior without a mentor to help me through figuring out how to refactor my code into these patterns only when needed).

I'm under 50 and read the GoF book ;)

I'm one of the rare people who was writing vb and then c# during the terrible Java j2ee days. Then I got a job in a startup using Java which avoid the 'enterprise' idioms. So my experiences with Java over the last decade or so have been mostly good (except for a foray into Hibernate, never again - jOOQ for life). No crazy class models, no xml configuration, etc...

Amen to esoteric Spring issues. I once dealt with a jar that suddenly started failing despite no code changes because Spring uses the order of files in the zip file/jar to determine initialization order. Turns out one that particular time files ended up in a weird order inside the jar file.

It's natural to read and initialize the classes as they come, _unless the code defines a specific dependency order_.

This looks like a developer simply did not declare proper dependency between classes/beans.

Try doing the same with CORBA and DCOM.

If Common LISP had become popular I think there would be a popular distaste for everything about it and people would be wishing they could write code in PHP, Visual Basic, COBOL, Cold Fusion, etc. (There was a popular distaste for Common LISP at the time, it was hard to find a LISPer in the 1980s who liked it. Half of that was it was hard to fit it into a 16-bit machine and wouldn't become really implementable on microcomputers until a 32-bit OS was available... Thus BASIC got another decade of life extension.)

Until Java came around every book on Object Oriented programming (say "C++") had examples such as "Stack", "Queue", etc. In the case of Java you saw people starting to write objects mirroring the business and application domains. People who were trying to use objects in Smalltalk or C++ in 1990 just weren't accomplishing enough that somebody could step back and say "object orientation sucks", rather they were getting stuck and blaming themselves or blaming the tools, rather than the concept.

I see this repeated all the time.

What people fail to realize is that the enterprise culture is language agnostic.

Before Java we were doing the same with C, C++, VB, Delphi, Smalltalk and whatever 4GLs one wants to dive into.

When Java gets replaced by TechX, the space ship enterprise architects will keep doing what they know best in TechX.

> The overuse of design patterns, etc.

Java has been trending away from this for some time now. A modern Spring app looks nothing like an old J2EE app.

A lot of us jumped off the Java train in disgust at the height of the J2EE craze and never looked back, so fairly or unfairly we'll forever be judging everything Java by that tainted memory.

A framework originally designed for Objective-C, actually.

Wait, is that true? I know WebObjects was designed around ObjC, but a quick ten seconds on Wikipedia doesn't indicate that J2EE was designed around ObjC initially.

----

Unnecessary opinion: I don't like either, but WebObjects sucks about 1/10th as much as J2EE.

You should have spent more than ten seconds.

> By the time DOE, now known as NEO, was released in 1995, Sun had already moved on to Java as their next big thing. Java was now the GUI of choice for client-side applications, and Sun's OpenStep plans were quietly dropped (see Lighthouse Design). NEO was re-positioned as a Java system with the introduction of the "Joe" framework, but it saw little use. Components of NEO and Joe were eventually subsumed into Enterprise JavaBeans.

Taken from https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere

Ah, I was just quickly reading on the J2EE wikipedia entry and didn't see "Objective" anywhere on there.

You're absolutely right, thank you for clarifying!

No issues, and here is another one, while Java might have a C++ like syntax to make it more appealing to mainstream, its main influence was Objective-C, not C++.

https://cs.gmu.edu/~sean/stuff/java-objc.html

Hence interfaces, dynamic loading, reflection and so forth.

Interesting.

Bringing it back to a previous point I made, I met someone who claimed to have helped port over the WebObjects framework from Objective-C to Java, and he claimed that while it's not a 1-to-1, you can fairly easily map a lot of the Objective-C semantics to Java, making the porting process not that hard.

Yes, they are quite close.

Objective-C related content,

https://developer.apple.com/library/archive/documentation/Le...

Java variant,

https://developer.apple.com/library/archive/documentation/Le...

Yep spring since 1.12 here.

Modern Spring Boot is still incredibly bloated and full of questionable design patterns. A simple web application should not consume hundreds of megabytes of RAM by default and startup time on modern hardware should be basically instantaneous. Classpath scanning and annotations are still massively overused and most of the time they're accomplishing little more than obfuscation and turning compile time errors into runtime errors.

Why exactly? How often do you start up a web application? And it’s not like the RAM is not there to use it — thread pools, db connection pools, etc have to be set up.

Since that's an hour-long video, what do you consider the most salient points of his plan for Java that it ended up embodying eventually?

About user-grown features. Over time, Java let users expose more lower level details to the language than before.

But, really, watch the talk. It's one of the best conference talks in computer science history.

Just like any other language, in order to use Java well you have to ignore a lot of the hyped up techniques.

Overuse of design patterns seems like decades ago.

Sadly it is not: they still get taught, and then juniors come and they expert-beginner projects to death. And yes in 2022 expert-beginner is a verb! Cheers

it is painful watching this video . presentation software and projectors are truly blessing

Java's (Oracle's) strategy is to spend most the innovation on the runtime, and in that regard, it's probably the most advanced platform. The net effect is that you can write some pretty naïve and boring OO-style code that will almost always perform superbly. This is a good thing, and something that I envy as a C# programmer.

Writing Java in my day job currently, I really miss C#. It feels slightly more like a "Java done right" -- the same strategy of bringing "fancier" features from F# or other languages, but it has just a _few_ more features that make day to day development just a little more pleasant.

C# is an excellent contrast. It has always moved quicker than java (not hard), but that has left some features that in retrospect seem half baked. For example they needed some sort of function reference thing, so we had 'delegates', but then later we got lambdas with LINQ. And although LINQ has a lot of good parts, I'm not sure the expression bit was a good idea even people familiar with SQL linked it.

And reified generics are nice for c#, but a right pain if you want to implement another language on the CLR which isn't very c#-ish.

More recently I'm still not sure why, in a language with an extensive runtime and its own VM, they went with async / await rather than fibers or continuations like go and java. It was probably simpler to implement initially, of course.

Even slow moving java shows that bad decisions have a cost down the road even if the features are unused: there can be monitors on any object to support synchronisation, serialisation similarly lurks around internally.

> More recently I'm still not sure why, in a language with an extensive runtime and its own VM, they went with async / await rather than fibers or continuations like go and java. It was probably simpler to implement initially, of course

Async/await work much much better than goroutines for GUI programs, which was still a major market at the time this feature was added to C#. Since there is a single GUI thread where everything that touches the GUI must live, but you do want your application to have multiple other threads, you need to give the programmer this kind of control and can't rely on a more simplistic Go-style green threads runtime.

I believe COM also has some similar requirements, but I am less sure than I am for GUI.

Finally, C# has a lot of influence from the functional langauge community, so it's possible that async/await and Task values were a more appealing solution given those particular tastes.

> Async/await work much much better than goroutines for GUI programs, which was still a major market at the time this feature was added to C#. Since there is a single GUI thread where everything that touches the GUI must live, but you do want your application to have multiple other threads, you need to give the programmer this kind of control and can't rely on a more simplistic Go-style green threads runtime.

Couldn't you have the GUI thread on one core, and the "goroutine pool" taking all the other cores, and distribute work on that pool? The model would be a bit more complex than Go, but considering C# is made for a wider variety of usages, multiple models wouldn't be so far fetched.

> Since there is a single GUI thread where everything that touches the GUI must live, but you do want your application to have multiple other threads, you need to give the programmer this kind of control and can't rely on a more simplistic Go-style green threads runtime.

Isn't that just a limitation of Go since its goroutines all run in the same pool? As far as I know, in the Java implementation you'll be able to create virtual thread pools from regular threads (i.e. the gui thread) and then have another virtual executor for the rest of your program. You'll still have the backend vs gui split but you won't have the entire async await split for the rest of your application.

I mean, technically, you don't have to have async/await in C#. Nothing's stopping you from using threads from the thread pool.

IIRC, they went with async/await because it could be implemented through desugaring in the compiler using a technique similar to what they had implemented a few months earlier with IEnumerable. That is to say, the team was thinking about desugaring at the time the need for asynchronous functions arose and they were not thinking about CSP. Remember that C# was in production at the time and they needed something that would not potentially upset the world.

> More recently I'm still not sure why, in a language with an extensive runtime and its own VM, they went with async / await rather than fibers or continuations like go and java. It was probably simpler to implement initially, of course.

No one was willing to approve another extension of the old runtime, and a major one at that. If they had already completed the .Net Core rewrite back then they would've probably baked async into the runtime.

Nah, C# has a shitton of more features, some of them indeed making the day to day development more pleasant, while the other ones are known only by a handful of people, has strange interoperability with everything else or is superseded already by another one. It is really on the way to become as complex as C++ is.

Could you list these features? I was under the impression that apart from some things that can be easily done in C# but are pretty much impossible to do in Java (like value types* and pointers) the languages were pretty similar.

Some C# things seemed rather strange (like delegates), some purely cosmetic (like indexers) and there were also things that Java had but C# did not like covariant return types (available from C# 9.0)

*Project Valhalla is supposed to bring it to Java but I wouldn't hold my breath waiting for it.

The "dynamic" keyword [1] is my favorite blunder in C#. It's great if you are use it for COM interropt but it's awful otherwise.

The code compiles but from time to time it fails at runtime and performance are sometimes Ok, sometimes not depending on the call stack.

[1] https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

dynamic is amazing for the extremely niche use case of interop with dynamic languages. I had a system which executed Python scripts on devices using an orchestrator written in C#. With dynamic and IronPython, I could seamlessly unit test the whole enchilada without writing un-Pythonic Python or ugly C# wrappers.

Accessors come to mind:

    class Foo {
        int Bar { get; set }
    }

Allow you to get/set the value of someFoo.Bar as if it were a public member. If you want read- or write-only members, you just remove the "set" or "get" portion. If at some point you need to add logic to the setter, you just do

    int Bar { get; set { /* setter logic goes here */ } }

You still use assignment syntax ("someFoo.Bar = newValue"), but this syntax is desugared into a call to the setter method. Ditto for the getter.

IMHO they make class APIs much cleaner and forward-compatible (on the other hand, if you started with a public member and then need to add a proper setter with some logic, you would break the API).

Also, non-nullable types are a pretty nice way to avoid checking for null every other line of code.

And these are literally just the first couple examples that came to mind.

I think this is can be handled with Lombok using @Getter and @Setter annotations (https://projectlombok.org/features/GetterSetter). It is not exactly the same because you call generated methods instead using assignment syntax but I guess it's close enough - if you need some custom logic in the getter/setter then you remove the annotation and write your own implementation (I think Lombok might be smart enough to ignore the annotation if an appropriately named getter/setter is present).

Non-nullable types sound great, I wonder if this could be introduced to Java in a backwards-compatible way (I suppose it would follow the same path with introducing explicitly nullable types first, though I guess it could be handled using Optionals?).

If you need a shortcut for accessors, you may aswell make your fields public and avoid get/set altogether...

This allows you to override the logic later. Public fields in a language where "x.y" means "directly access field y on value x" don't allow that; x.y forever means "directly access field x" and you can't later interpose code between attributes and the code accessing it.

This isn't the only way of doing it, depending on your language. Python has a completely different mechanism where a class can start with a directly-accessed "y", but in a later version make it a property. (More than one, actually.) Some languages route all property accesses through something you can hook. Some languages simply automatically do what C# is doing here.

Semantically and abstractly, there's no reason to every not be able to override a property access in later versions like that, because it is so darned useful. Unfortunately, performance wise, it's hard to beat a language that guarantees structure layout and guarantees that x.y can be compiled into a single constant memory load instruction, and unfortunately, you can't just wave "compiler optimization" at the problem and make it go away (considered in isolation this seems like an obvious solution but as usual as it starts interacting with all the other features it gets much harder than the simple cases). The higher performance languages have a strong reason to give people ways to get guaranteed direct struct member accesses.

Though please note that if you "upgrade" anything from a field to a property, you need to recompile any dependencies. Otherwise they will obviously try to invoke the field that no longer exists, instead of calling the property methods.

Not if you need to implement some setter logic though, or want to reserve the option to do so in the future. And not if you want those instance variables to be available as JavaBean properties.

I haven't developed in Java in a long time, but public instance variables were a no-no when I did for these reasons.

Why not start incorporating Kotlin? It's basically what you want, is an easy transition and has JetBrains' backing so the tooling is there...

> [C#] feels slightly more like a "Java done right"

This is how I feel about Kotlin.

> Java isn't sexy, for the most part.

In 1996, Java was pretty darn sexy. Managed runtimes in a high performance[1] language were an absolute revelation at the time.

It's absolutely true that as it evolved, Java grew to embrace the affects and aesthetics of its biggest customers (Enterprise backend coders). And that's not sexy at all. But at the time? We all thought this was going to be the systems language for the next century.

[1] Almost. At the time this email was written, the first JIT JVM was still a few months out from its early beta releases. But Gates could absolutely see where the wind was blowing.

It was about 10 years ago that the community agreed that it was the JVM that was successful. It's a platform with multiple viable languages. Scala obviously comes to mind. Kotlin is a somewhat mixed case because its popularity comes from the mobile world where you don't really have the JVM.

Java is not the most pleasant language for sure. It started as a dumbed-down as golang was (still is?) for years. It's still catching up with C++ (e.g. see all the Valhalla project discussions on HN). It certainly shows its age. It's not clear to me why so many people are still fixated on Java when solid alternatives have existed for years within the same ecosystem.

Also, if you don't like JPA try JOOQ.

Kotlin is pretty popular on the server side too, and Kotlin (the same compiler) generates JVM bytecode for both mobile and server in the same way because Android very much has a JVM.

How could it catch up to C++? They are not even in the same category of languages, other than some surface level syntax, they are as different as they get.

> It's not like C++, where the template language is both Turing complete and the fastest way to summon Beelzebub from the depths of his infernal pit, and where you need a team of PhDs to decide which version of `auto_pointer` actually works the way you think it does.

Value types on the JVM have been described as "6 PhDs, knitted together". In C and C++, this is just struct.

> It's not Javascript, where the framework your front-end lead sold you on last week has already been superseded by the hot new thing.

You should stop spreading stuff like that, it's false. React has been the most popular frontend framework for 6 years at this point, and Express the most popular backend framework in JS for at least 8 years. The backwards compatibility of JS is at least as good as Java, ES5 and ES6 were great upgrades (a bit like Java 5 and 8 in a way).

I like Java and I think it's very important. I can say that without feeling the need to dismiss other languages that are as important as Java to the modern world.

> 6 PhDs, knitted together

But that is regarding the implementation/specification. For the users it will be two new keywords and .ref. It will even ease the language by healing the rift between primitives/objectsz

C++ has been used by lots of people without PhDs to great success. The language is not perfect, but for most people it's far from the hell that's described in the comment I replied to. Some people will complain about the AbstractFactoryBeanInterface in Java and say that it's hell, they are the minority. Same with C++.

I’m not saying that C++ needs PhDs to write, but it is one of the most complex languages out there. Even just basic usage is considerably hard (RAII, r/l-values, etc). Of course it is in part inherent in the system programming domain.

But Java is a trivial language comparatively, your mentioned complexity is user-generated.

It's interesting that you find RAII hard. I've not heard this opinion before.

Well, correctly writing all the copy/move constructors is hard.

> It lets a lot of innovation happen in other languages

Only if you're defining innovation as syntax and semantics to the language. Java has been the pinnacle and cutting edge of language implementation innovation decades - Sun/Oracle is/was the Bell Labs of VM and JIT research.

> It lets a lot of innovation happen in other languages, then takes the successful parts for itself

The only time I've ever had to use Java was for a computer science class, and I thought it was a solid language (pun intended), but I hated its half-assed attempt at operator overloading.

I think it's a major feature that's long overdue to be fully implemented in Java, because it's already used for some of Java's built-in classes and it's proven useful in many other programming languages.

Most of Java seems very well-thought-out to me, but for some reason they decided to add only some operator overloading, instead of planning ahead more.

I remember hearing somewhere that they were planning on adding operator overloading, but last I checked it didn't look like it was going anywhere.

Java chose not to implement (general) operator overloading because it's really hard to do right. We're left with just a fluent syntax for appending text to strings.

Java was one of the first language specifications to be written by adults (maybe Common Lisp was the first, but it drives Common Lisp fans crazy to compare Common Lisp to Java, Python, etc.)

Python's operator overloading works remarkably well given that it has a very simple model (always look to the left hand side to decide how to interpret the operator.) C++ on the other hand ought to make anybody skeptical of the idea, but C++ would make anybody thoughtful and sensitive question the idea of computers entirely.

> Java was one of the first language specifications to be written by adults (maybe Common Lisp was the first, but it drives Common Lisp fans crazy to compare Common Lisp to Java, Python, etc.)

I think ALGOL was first, in the ALGOL 60 Report (https://en.m.wikipedia.org/wiki/ALGOL_60#History). COBOL may have had a good spec around that time, too.

There were older languages with specifications, but those specifications were looser, with languages partly defined by their prime implementation.

Well, neither Java, Common Lisp nor ALGOL60 support operator overloading, so there does seem to be a trend there.

Common Lisp in fact, as most lisps, has no support for "operators" in the infix sense at all. If you have a need for a very algebra-heavy portion in your program (say, a linear algebra library), the best idea would be to define a DSL for that particular algebra - especially since this will give you much more control over efficient evaluation than using the built-in evaluation order.

A good example of the limitations of simplistic operator overloading is matrix algebra: A+B•C can be computed efficiently as a ternary operation, more efficiently than doing A+B then multiplying the result by C. Now of course, you can implement this in C++ by having operator+() return some kind of matrix_addition object, and then defining the efficient operations in operator*(matrix_addition, matrix) etc, but that is much more roundabout than defining a simple addAndMul(A,B,C), or an explicit optimizing DSL.

There are reader macros which provide a more math-like notation. Those are translating the math syntax into Lisp s-expressions at read-time.

Yes, that's the DSL concept I was talking about.

The lack of operator overloading makes it impossible to implement new numeric types in a consistent way. For example imaginary numbers or numbers with units.

You can make the case that both intX (x=16, 32, 64) and floating point are bad for general purpose computing. Like Common LISP and Python, Java has bigints and rationals in the stdlib, but Java makes you use non-operator syntax to get at them. Contrast that to Clojure which puts them on your fingertips.

Java has always been in a strange place of not deciding if it wants to be a systems or application language. (The standard architecture is that demanding systems, say video games, are written in both a systems language and a scripting language. A Python coder feels smart when the incorporate, say, number is written in C or FORTRAN but Java’s xenophobia makes that feel like a personal failure. Java is ‘good enough’ for applications programming that you might find something like Spring or Guava gives you all the dynamism you need with less hassle than adding an embedded scripting language like Groovy or Clojure.)

If there's no implementation on the left, python then looks on the right.

If you are serious about using the JVM, I would suggest Kotlin or Scala as a better alternative to Java as they have all the libraries and greatness of the JVM but they have less of the historical baggage that Java brings with it.

Both can be written in a Java like fashion to start, and have 100% interop with Java (you can mix the languages in projects) so the learning curve is pretty alright.

That is the frying pan to the fire.

JDK 17 has most of the good features of Scala and Kotlin.

Scala seems to be designed so that you can write a short book with very fluent and natural looking demos. Make a small deviation from that and there is nothing fluent or natural about it.

Kotlin is OK but isn't sufficiently better than Java to be worth using when any Kotlin dev is going to have to know Java and Java-Kotlin mapping pretty well to use libraries. (It's a similar problem to Typescript.)

Both Scala and Kotlin are sufficiently similiar to Java to provide no real benefit. I'd point to Clojure as a language that is radically different from Java AND that takes advantage of the strengths of the JVM to be worth the cognitive load of having to know both a new and old language to be productive.

> JDK 17 has most of the good features of Scala and Kotlin.

I keep reading on HN that "Kotlin isn't much better than Java X". Having used Java and Kotlin (mainly targeting JVM) full-time for 6 years, this doesn't match my experience at all.

Here are some of my favorite Kotlin improvements over Java that I leverage all the time:

* Much improved type system (nullable types, function types, declaration site variance, type aliases, contracts, better type inference, reified function type arguments)

* Local variables are final by default ("val")

* Type-level distinction between read-only and mutable collections (but compiled to Java collections under the hood, so no conversion required when interacting with Java)

* Much improved collection API

* Much improved lambdas (e.g., no pain points w/ mutating variables and checked exceptions)

* Extension functions (incredibly useful in practice)

* Much better DSL capabilities (great for UIs, generating HTML, etc.)

* Lazy properties (more generally: delegated properties)

* Coroutines (looking forward to Java's Loom; by then coroutines will have dramatically improved my async code for 5+ years)

* Great serialization support (kotlinx.serialization)

* Pragmatic macro-like capabilities via inline functions and compiler plugins (removes lots of boilerplate)

* Multiplatform support (JVM/JS/WASM/native; Graal native image is a good alternative to Kotlin/native and also works for Java)

Although I'm glad to see that Java is still improving, it will never get close to Kotlin. The most obvious reason is that many of Java's early design decisions were revised in Kotlin but are impossible or impractical to revise in Java. Also, Java carries the burden of being a platform language, whereas Kotlin can focus on being the best possible application language.

These days, I only use Java for libraries intended to be used from languages other than just Kotlin. In that case, I don't want to force Kotlin on users (stdlib dependency, debugging, etc.).

> Kotlin is OK but isn't sufficiently better than Java to be worth using when any Kotlin dev is going to have to know Java and Java-Kotlin mapping pretty well to use libraries.

One of the big benefits of Kotlin is that if you know Java, you pretty much already know Kotlin, too. A good Java dev can get spun up on the basics in a day or two.

> Both Scala and Kotlin are sufficiently similiar to Java to provide no real benefit.

Kotlin provides a ton of ergonomic features that I absolutely adore. Named parameters and default parameter values alone save me tens or hundreds of lines of code.

I think of Kotlin as what would happen if a Java developer looked at Javascript and asked "okay, but what if this didn't suck?"

> I think of Kotlin as what would happen if a Java developer looked at Javascript and asked "okay, but what if this didn't suck?"

I think you mean "what if we took C# and put it on the JVM"? /s

Honestly, C# has had most of the features Kotlin "adds on" to Java for years, even decades.

Kotlin's future is tied to Android, on the JVM I don't even care it exists.

How so? While yes Android is one of the most common uses at the moment for Kotlin (thanks to Google making it a first class supported language for the platform) it is still dependent on the JVM, thus can do anything that Java Can.

You can’t beat Javascript for ergonomic passing conventions and packing and unpacking of lists and dicts.

> Both Scala and Kotlin are sufficiently similiar to Java to provide no real benefit

Sorry but "no real benefit" seems to come from a position of ignorance.

I can only talk about Scala which I know pretty well.

While Clojure is a radical departure from Java, being a Lisp, Scala is a departure thanks to its type system and features that help you writing more functional (as in functional programming) code. And I mean this in a good way: it helps you avoid mutations and side-effects, while giving you the freedom to use good old OOP if you wish so. In general it provides tools that help you better express your intent that Java doesn't have.

I think that Java has too much baggage to ever become as good as Scala, especially on the type system side, and, in addition, Scala is also moving forward.

Also don't forget Scala.js [1], which is rock-solid and just plain amazing, and Scala Native [2].

[1] https://www.scala-js.org/

[2] https://scala-native.readthedocs.io/en/latest/

Honestly, the null safety and constructor initialisation of properties in Kotlin alone make it worth it.

> JDK 17 has most of the good features of Scala and Kotlin.

I'd be sooo happy if that were the case, but sadly, it's not. From the point of view of Scala, I still see many features missing. Roughly in the order of importance:

* Immutable persistent collections in the standard library (and thus lingua franca in the libraries). Just so much better than mutable collections. Way less headache. Once you start using them, you realize how rarely you actually need mutable ones.

* Pattern matching. Java will surely improve on what is currently available. But why wait? It may take a long time.

* Sophisticated string interpolation. It's powerful, and yet is still easy to read. Again, Java is on its way to get it, but with Scala you can have it right now.

* Type Classes. Sometimes it is very good design to separate data from functionality. Java designers (Brian Goetz IIRC) mention they would like to get this eventually. Scala has an interesting design of Type Classes -- "givens" -- which is also modular (in contrast to Haskell). Scala also has an elegant mechanism for Type Class derivation using the "derives" clause. https://docs.scala-lang.org/scala3/reference/contextual/deri...

* for-comprehension syntax and IO/Task/ZIO for async programming. Project Loom still hasn't delivered. But Scala has you covered. It gives you for-comprehension syntax, so that you don't have to suffer from nested callback hell. And there are many great libraries for async programming, like ZIO or Cats Effect. These are easier to work with, compared to other Futures from various Java libraries, because they're lazy, not eager. for-comprehension syntax is also useful for other things, it's just that async is the typical usecase.

Higher-kinded types. Not everything has to be super fancy higher-kinded type-level craziness. And very often one gets away without needing to use higher-kinded types and that's good (just as often a solution without parametric polymorphism aka generics is enough). But other times it's awesome to have this power of abstractions. Typically, but not only in libraries.

* Object. Sometimes you just need to have an object (which might implement an interface/class/trait). But Scala doesn't force you to create a whole class, if you only even want just one instance anyway. A small thing, but way more elegant.

But I'm really happy to see Java/JVM improve. The 17 release has brought some great features, but in the language level (records, embryonic pattern-matching, ...) and the VM level (GCs in particular). We all benefit more or less directly, one way or the other.

Also, Scala’s optional null checking (where null becomes a type that is not at the bottom of the type hierarchy) is really cool!

All in all, I do find using Scala can absolutely worth it, but I really don’t feel it with Kotlin. It feels like a watered down Scala, and add to that where modern Java currently is, I feel it is not needed.

Also Java doesn't run on android? Not 17 anyway...

I guess you could try to argue mobile is bad or something, but you get Kotlin not JDK on mobile.

Yes, Clojure is probably better, but on the flip side as a developer knowing Java 8 and Kotlin is better than knowing Clojure and JDK 17. Perhaps you can point to some salaries here but Java developers are not in short supply, if you wanted to play that game there are better languages for more lucrative payout (assuming you can even get them, these tend to be boutique shops not generally hiring publicly)

The fellowship of Kotlin at Mountain View will ensure that Android Java stays as it is, any further improvement might happen only if the community is very vocal about any Java library on Maven Central that fails to target Android.

However they will most likely assign an intern to port it to Kotlin than improve Java's support on Android.

Scala has just as much historical baggage imo. It's community is split between functional zealots and "better java". You also have the Scala 2/3 split that is currently going on and just the general complexity of the language makes it not so appealing.

IMO if you're serious about using the JVM you should be using Java 17 and following the latest version. Kotlin is usable, but it doesn't bring that much more to that table other than longer compile times.

Why do you feel that Scala has just as much historical baggage? Isn't the whole point of the Scala 2/3 split to remove historical baggage.

The community split is what makes Scala better in my opinion. The fact that you can have the split between functional first and better java people is a nice thing to see over Java where if you want to do functional programming, you are a second class citizen.

I was really into Scala ten years ago, but felt that a "Scala--" might be more accessible to most devs and hurt Scala adoption. Lo and behold, we got Kotlin.

But isn't the great thing about using the JVM supposed to be not using Java?

Or at least the perf advantages it brings. Java has nice stuff today maybe but one could argue that it is primarily defending market share that caused Oracle to move forward with its language updates.

I'm inclined to say the opposite, the more the JVM stays healthy and the stronger the third party ecosystem the more likely it doesn't become a 'dead' language like COBOL or FORTAN (not dead but in terms of marketshare).

They may have a little less of the historical baggage, but that's still a lot of baggage. Same goes for F#. It's a shame that three of the best programming languages in existence are built on top of Java and C#, instead of doing their own thing. Admittedly their VMs are mostly fantastic, but trying to reuse libraries and language constructs has just created more problems.

Some say "historical baggage", others say "backwards compatibility"... two sides of the same coin...

And lets not forget that the JVM runs all kinds of things that aren't Java. So Java devs who get bored can write a few packages in whatever new hotness they like until either they're sated, Java catches up, or all new development moves over.

Whats the productivity coefficient for Java? Or Javascript? Or Python? or Ruby? Or Assembly? or C?

I only ask because I've never gotten a straight answer with an actual number.

Because there is no way to define such a number. We only “know” as per Brook’s famous paper, No silver bullets that this number has not passed a cumulative value of 10 in like 3 decades now, since the first programming languages. The only way to increase productivity is through code reuse - and given the flourishing JVM ecosystem, Java has that as a big plus.

One of the biggest turn off to me of java has always been the poor quality of many java apps. Especially on mac, you know when its a java app vs native.

Can you give me an example? Java is used for so few user applications, the only project I can think of is IntelliJ, which is an amazing project.

I use jetbrains apps on mac. I like them a lot, but they aren’t mac-like even now. In the past they were even chunkier.

SPSS comes to mind too.

SPSS doesn't come to mind as having developers that would bother to read Filthy Rich Clients kind of books, or Apple extensions,

http://filthyrichclients.org/

https://developer.apple.com/library/archive/navigation/index...

My mind goes to the original Arduino IDE, or Weka Studio. I know these are pretty indie projects in the scheme of things, but still.