When people say "composition over inheritance" in Java discussions, they usually mean the trivial modeling rule: prefer has-a over is-a.

But that’s not what composition is really about.

The deeper idea is interface composition -- building types by composing multiple behavioral contracts behind a single cohesive surface.

Java provides inheritance and interfaces, but it doesn’t provide first-class delegation or traits. So most developers never really practice interface composition. They either subclass, or they wire objects together and expose the wiring.

The slogan survived. The concept mostly didn’t.

The manifold project, for example, experiments with language-level delegation to make interface composition practical with Java.

https://github.com/manifold-systems/manifold/blob/master/man...

it really depends on your project, and what framework(s) and libraries you choose to use.

Java still has a tonne of legacy projects using old(er) frameworks that rely on such patterns - spring has some old versions which is like that, and i am certain plenty of java projects are retaining those old versions due to lack of desire to upgrade.

If you're starting a greenfield development in java, you surely would not befall into that factoryfactory pattern (unless you're just copy/pasting old projects around...). But i imagine there's way fewer greenfield projects compared to older projects requiring maintenance.

It’s still very much an annotation festival in the code, making the framework quite lengthy to learn for newcomers (gotta learn Java and the whole quarkus annotation DSL with it).

Go is verbose, but it is much more explicit and only uses standard language things instead of a whole annotation DSL.

https://www.wildfly.org/

I think this is an often overlooked solution to some of the problems we nowadays tend to approach the clown for.

As for build systems, Maven is old and cranky but if something else replaces it, it will probably be quite similar anyway.

Maybe it's innate to trying to use a a fully fledged server-style framework in a serverless context, but I don't think it's suitable. In fact I think the whole idea ("Hey, let's bludgeon spring-like metaphors into an entirely new setting") was a poor one.

Java itself I've enjoyed more and more over time as the language has evolved into something much more expressive, and without all the enterprise crap. My hope is that one day frameworks like Micronaut will end up discarded too.

I'm writing my own programming language right now... which is for an intensely narrow use case, I'm building a testbed for comparing floating-point implementations without messy language semantics getting in the way.

There's lots of reasons to write your own programming language, especially since if you don't care about it actually displacing existing languages.

Compiler writing can be an art form and not all art is for mass consumption.

> Java has won (alongside many other winners of course), now the AI drawbridge is being raised to stop new entrants and my pick is that Java will still be here in 50 years time, it's just no humans will be creating it.

This makes no sense to me. If AI possesses intelligence then it should have no problem learning how to use a new language. If it doesn't possess intelligence, we shouldn't be outsourcing all of our programming to it.

The vast majority of programming languages ever created never aspired to win and I don't think that's going to change now.

Source? I'm not saying you're lying but I have never seen any Java project build as fast as Go

well there's your problem - why are you using spring for a personal project, when there's so many other simpler, lighter weight frameworks around?

1) No immutable types. My work team is a huge user of immutable data stuctures in Java to make sure data passed around to other teams isn't changed. Go doesn't really have a good way to do this.

2) Refactoring can be really annoying (or at least really noisy) because of public/private being defined by capitalization of method/field names.

3) Error handling isn't great. I love Go's errors being just normal values, but the `error` interface is awkward when trying to figure out what kind of errors can be thrown without having in-depth knowledge of the kinds of errors that can be returned. We regularly need to make different decisions depending on the kind of error returned. Knowing which errors can be returned in Go is not defined by the method being called (only in comments).

- Java is a high-level, multi-paradigm programming language

- Go is designed as a systems language to supersede C projects at Google

Now Go identifies as a general purpose language that competes with Java? It's a free country, I guess.

TypeScript is a superior programming environment for the browser, for sure. Using it on the server? Why not, if you're not trying to scale (in capacity, or functionality).

Language-agnostic serialization exists for a good reason. It's not always right, but it's almost always the right thing to do.

that's an excuse imho. It's a post-facto justifying using js on the serverside because of familiarity.

I know because the exact same reason was given for GWT (google web toolkit), and that failed pretty horribly (despite it being quite good imho).

Are you joking? IntelliJ is without a doubt the best dev tooling environment available.

E.g. on the GC side Java is ahead of any other platform, especially with the low-latency ZGC garbage collector.

Bright future for it just means it is not planning to become 40th or 400th.

(My prediction - in next ten years java will always be among top 6; new language might come to the very top and some leapfrogging game between c# and java)

And then there‘s also Micronaut, if you prefer compile-time setup to Spring.

A completely different culture of Java usage can and does exist a lot of places. It is absolutely true that success creates a certain ossification of practice. But SpringBoot is not necessary, any more than Guice or any other framework-y thing.

Subjective experience, but largely agreed.

Vague rant that summarizes my own experience: major version updates kind of suck, even if Spring Boot is still better than regular Spring (I've gone through the XML hell, was not fun, even less so with a separate Tomcat instance that we had to deploy to, instead of an embedded one). In practice their huge effective pom.xml also leads to conflicts when your package needs something else and it feels a bit arcane to override things. There are things that have underlying technical reasons for being the way they are but seem stupid from afar - like how @Transactional doesn't work when called from within the same bean. Personally I also prefer code over convention for configuration and initialization so the whole annotation driven setup feels quite annoying and difficult to debug when things go wrong - but even the code configuration isn't always great and sometimes it feels like they have abstractions for the sake of abstractions. Spring Boot also often brings friends like MapStruct or Lombok or Mockito which add even more dynamic behavior and issues when you update JDK, alongside slow testing with JUnit and unpleasant debugging of jumping through numerous abstraction layers. You don't strictly have to, but people will.

I probably should have written down every complaint with exact details (so those could be picked apart as user error) over the years that I've been unfortunately maintaining and building shitty software with Java, but I will say this - modern Spring Boot isn't wholly horrible, it has a pretty rich ecosystem and you can do a lot of things with it, but the overall vibe I get from it ofen can be summarized with "Eww." I'd end up using it because I have to, or because it's a means to an end ("Hey, we need to build an event-driven system to integrate with a bunch of others, you have two weeks"), not because I want to.

For the sake of comparison, I believe that for plenty of the folks even Dropwizard would be worth a look: https://www.dropwizard.io/en/stable/ it is more or less like some glue around a bunch of idiomatic packages in the Java ecosystem and it's not horribly hard to integrate something that you want yourself (e.g. Dagger 2 for DI, at this point I'll take anything that does as much as possible at compile time https://dagger.dev/dev-guide/).

Or, for a more modern spin, Quarkus isn't too bad either https://quarkus.io/ or maybe Micronaut https://micronaut.io/ or perhaps Helidon https://helidon.io/ with neither of those being strong recommendations - figure out what you like for yourselves. For people that have been luckier than me, that might as well be the very same Spring Boot, just on better projects. JVM is a pretty cool piece of tech though, and so are the JetBrains IDEs with their refactoring features and nice Maven integration.

   var wg = sync.WaitGroup
   defer wg.wait()

   wg.Add(1)
   go func() {
      defer wg.Done()
   }

And create a separate channel to return errors from a goroutine. Definitely more work.

In terms of async, it's when you have to have a function with "async" attached to it and making it so that only other async functions can call async functions.

It ends up creating a weird circumstance where you can end up with a lot of duplicated APIs, particularly in libraries, because you are providing both async and non-async versions of functions.

[0] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

The terminology is used to talk about languages that have async and sync functions where you declare (or color) the function as either async or sync.

In these languages it's pretty common for the language to enforce a constraint that async functions can only call other async functions. Javascript / Typescript, Python are popular examples of languages with colored functions.

In this context: functions anotated with async

"Stackful coroutines" allow yielding from any arbitrary point. They're basically fibers, except with the explicit control transfer and value passing yield and resume operators; there's no hidden or implicit control transfer like with green threads. Though, some people would argue allowing any function to yield without announcing this in their type signature is tantamount to hidden control transfer. Personally, I don't see how that's different than allowing any function to call other functions, or to loop, but in any event languages are free to layer on additional typing constraints--constraints that can be tailored to the desired typing semantics, rather than dictated by implementation details.

Stackless coroutines are typically implemented as a special kind of function whose state is allocated and instantiated by the caller. In contrast, stackful coroutines are typically implemented by reifying the stack, similar to threads. The "stack" may or not be the same as the system's ABI stack.

In stackful coroutines, unless there are additional typing constraints imposed by the language for hygiene reasons, any function can typically be called as a coroutine or use yield and resume. There's no need to compile functions into special alternative forms as call frame management works the same whether invoked from a coroutine context or not.

The JDK and JVM has advanced so fast while android has been lagging. It's pretty frustrating, especially because google has been so slow to pull in changes from later java versions.

A part of me wishes that android would just dump their hokey dalvik, ART, and other BS and just use the OpenJDK or a fork of the OpenJDK with whatever special sauce they need. A lot of the project Leyden stuff lends itself nicely to maybe someday being able to run real java on android.

Edit: Apparently android is forking OpenJDK, since Android 7.

https://en.wikipedia.org/wiki/Android_Nougat

No, they didn't. Google happily used regular Java until Oracle played Oracle. Then Google stopped updating the supported Java language version and started diversifying away from Java.