cryptos

Lombok offers more than data classes, so Java records obviously cannot replace it completely. However, @RequiredArgsConstructor makes the code harder to understand. I prefer a visible constructor that shows which parameters a class needs. With modern tools like IntelliJ IDEA, generating (and updating) a constructor is easy, and the visual noise can be reduced by folding the constructor when it is of no interest.

Annotations like @RequiredArgsConstructor also encourage poor style, because there is no room for validation inside the constructor. At most, @NonNull adds null checks, and that is all. Lombok still offers many annotations that promote bad practice or have been superseded by the language itself, e.g. @Setter (mutability without protecting invariants), @Value (records) or @Cleanup (try-with-resources).

@Slf4j can easily be replaced by a single line of code (with the Log4j 2 API, even without specifying the class name).

Lombok's builders are actually useful, since Java has no named parameters with default values (as Kotlin does).

Regarding the "Dark Magic" section: just because other frameworks like Hibernate apply their own flavour of dark magic doesn't make it any better. Such magic should be kept out of the functional core of application code. The more magic is applied, the more problems can occur (e.g., the correct order in which tools apply their magic). This is essentially accidental complexity introduced to improve developer experience, but in the age of AI this may be the wrong optimization.

If you write modern Java, Lombok really doesn't add much.

But you could save some token with Kotlin, too. The language is a bit less "magic" and compiles faster. So, Kotlin might be a sweetspot for AI code generation. Go is probably another good candidate.

I liked Scala a lot, but it also caused some real world problems like different, partly incomprehensible coding syles or compatibility issues. Although the concise syntax could help to save some token, I guess that Scala is not the best language for AI. Other languages like Java or Go are more explicit and clear to the reader - and the AI. The elegance and conciseness simply doesn't matter so much anymore.

I could imagine some AI powered personal portal. This would basically answer the question "What is important and interesting today?". But that would have nothing in common with the old portals like Lycos.

This was also my first reaction. I'm always doubtful if projects add features that are not really close to the core use case.

Does anyone remember all these web portals from 2000? What people mostly wanted was a search engine but they added everything else and lost focus.

And in the end it might be a culture problem in the contexts Java is used in.

I've experience severe problems with Scala in teams with different skill levels or programming styles. Sometimes Scala code was very cryptic. As much as I like the elegance of the language as such, I've given up on it completely because it is not a good fit for industrial software development in my opinion.

The error messages are just advertising for Oracle consulting!

An interesting example to look at is Java vs. Kotlin. While Kotlin is a bit easier and definetly more fun, it didn't manage to gain a big market share in the Java space so far. I guess that this is the case, because Java is good enough and seems to be the safer bet (at least for managers).

I know and like Java for almost 30 years now. It is amazing how carefully the language is beeing refined. For the cultural aspect, yes, that is sadly true, but I have the feeling that the culture changes. More and more developers realize that there is a better way now (e. g. records instead of dumb classes full of getters and setters). Maybe the main problem is bloated frameworks and their stickyness. The Helidon framework, for example, is a breath of fresh air compared to Spring. Go developers complaining about huge Java frameworks and boilplate could be happy with it.

This article looks a bit superficial to me. The cloud has definitely advantages, like having the same data on all devices and it provides some kind of backup. The mentioned downsides could be adressed by better software archticture or e2e encryption.

Somehow money seem to damage personality. It's the same with David Heinemeier Hansson (who know Tobias Lütke in person), Elon Musk and many other folks.

That is basically true for every such system. Trust Signal? They could ship a backdoor in the next release. Same with Threema, WhatsApp (if you want to trust it today) and other services. You can expand that to the operating system as well. And who able to verify hardware security, anyway?

The right reason to hate XML would be some technical limitation or technical issues with it. But XML works quite well and is reasonable powerful. So the complaints usually boil down to: It is ugly and verbose.

Interesting point of view. JSON is also not the right thing to use in many scenarios, but it is the de-facto standard now. Maybe something like protobuf is the way to go.