Gradle could be used as an AI benchenmark on its own! The syntax of plugin DSLs changes all the time. Special credits could be achieved for handling old (Groovy) and new versions (Kotlin) of Gradle itself.
However, the cause it not really Java as such, but massive frameworks and tooling (e.g. Maven). Maybe AI will bring some fresh air to Java, because old truths might no longer be valid. But it will be hard to get rid of old habits because it manifested in AI training data.
My takeaway is that Go almost always prefers simplicity and not so much good software engineering. `nil` without compiler checks is another example, or designing a new language without generics. However the overall simplicity has its own value.
I don't like Bitwarden UI/UX. It looks not really polished. Especially the "folders" are akward. How the implemented it, calling them labels and designing them like labels would make way more sense. But the whole UI looks like software developers - and not designers - built it.
As others already pointed out, UUIDv7 is a solid choice and if you don't like the default representation, you can encode the underlying byte array with base62 for example, to get short, URL-friendly IDs.
That is not quite true. Google did much of the research OpenAI used to build ChatGPT. It is just that OpenAI came up with the first popular mainstream AI tool.
Just look what Google does with its Tensor Processing Units ... they are developing AI chips for a decade now!
This story reminds of Scala. The language as such is also fine, but has (had?) a cultural problem. There functional programming fundamentalists always promoting the purest solution without solid reasoning - as if god had decided that only pure functional programming is your ticket to paradise. In addition, Scala comes also with powerful language features to build abstractions, like traits, generics, and almost arbitrary names for classes, objects, and functions. All that lead to a culture of unreadably "try to be clever" code.
I'm not sure whether the Scala authors paved the way with methods like :\ (fold left) or whether that happened, because the language had the features, but I tend to assume the latter.
It is a great responsiblity of a language designer to think about what others might do with the language later. Regarding language features the rule "when in doubt, leave it out" applies. See Go (although not my favorite language).
So, basically Product Hunt has become a paid ads platform - only that you wouldn't pay Product Hunt but external service providers. I wonder why PH doesn't take the money directly and switch the business model to some kind of advertising auction. Might be more fair and transparent.
I had always the same feeling. KDE looks okay at first, but on a second look it would be somewhat ugly in a subtle way. That never changed for me in KDE, so I stopped looking at KDE some years ago. But maybe it is the time for another look!
The simple solution is to write everything (for the browser) in TypeScript instead and treat JavaScript only as the compilation target noone actually talks about. And compiling to JavaScript might also become a thing of the past with Webassembly. So, I think we shouldn't care about JavaScript as a name.
The first time I heard about Valhalla was 2014 (if I remember correctly), so more than a decade ago! However, I'm very happy how Java is engineered. It is really the exception that a technology is so carefully developed. Java is the technology you want for long-term stability.
One reason for that Java style is that Java was not such a powerful language for a long time. For example lambda expressions were only introduced in Java 8 (2014) and before that developers need to work around this restriction. A common workaround were/are some annotations above of methods and some reflection magic on top. For example a life cycle callback method annotated with @PrePersist is basically the same a registering a _function_. The whole Lombok library is a massive hack to circumvent some inconveniences in Java (and in my opinion no longer needed).
Especially yaml is overused these days. Kubernetes config or Helm charts (which in turn are also Kubernetes config) with hundreds or even thousands of lines are just horrible. XML with a decent schema would be a better fit - or to come back to the topic of the article: XML scales better.
That is a key point in my opinion. A typical stack trace of a Spring (Java) application can easily be 1000 to 2000 lines long. That is not so common in Go, as far as I know (I'm not a Go expert ...).
While I see some truth in the article, it misses the point of unimportant interruptions, which might kill productivity. A lot of meetings falls into this category. Many meetings aren't well prepared and are not held in a useful way. So, in my opinion, focus time and social interactions (meetings, calls, helping) should be balanced well.
The big problem I see with the practical adoption of REST principles is that a human can easily intpret a document and pick the desired transation (e.g. follow a link), but a program can not so easily do that. Maybe in the age of AI it becomes more realistic, but most of the time some "RESTful" back-end is used by a certain front-end application. What is needed is basically more like RPC. Maybe SOAP was closer to what we actually do and need. The specification and code generation was much better than what we have now with mediocre OpenAPI code generators.
Maybe gRPC or something like that will fill the gap ...
Letting AI generate code instead of writing it yourself as a software developer is basically the same as if a painter would generate a painting instead of doing the art himself.