> but when it was communicated with Mockito I perceived it as "Mockito is holding the JVM ecosystem back by using dynamic attachment, please switch immediately and figure it out on your own".

Who did the communication? Why is dynamic attachment through a flag a problem, and what was the solution? Why is "enable a flag when running tests" not a satisfactory solution? Why do you even need a _dynamic_ agent; don't you know ahead of time exactly what agent you need when using Mockito?

> While I fully understand the reasons that developers enjoy the feature richness of Kotlin as a programming language, its underlying implementation has significant downsides for projects like Mockito. Quite frankly, it's not fun to deal with.

Why support Kotlin in the first place? If it's a pain to deal with, perhaps the Kotlin user base is better served by a Kotlin-specific mocking framework, maintained by people who enjoy working on those Kotlin-specific code paths?

I'm curious, what exactly feels bloated about Java? I don't feel like the Java language or runtime are particularly bloated, so I'm guessing you're referring to some practices/principles that you often see around Java software?

Most of these arguments probably don't outweigh the benefits. If you're in need of a managed, highly-consistent, highly-scalable, distributed database, and you're already an AWS customer, what would you use instead?

Honestly, ORMs are just an abstraction. They come at a cost and they’re not a silver bullet, just like most abstractions. I believe the hate for ORMs in many cases is due to a lack of understanding/wrong expectations.

Disclaimer: You guessed it, I work at Oracle.

I never did proper benchmarking, but my feeling was that resolution played a role. When using 1080p things were fast, but the resolution is unusable on a 27" 4k display. When using 2160p things were fast, but too small for my eyes. Any resolution in between (this implies things are being scaled?) was sluggish.

Note that this is a 13" model, so the problem does not seem to be restricted to the 16" model that the author is talking about.

> You are probably doing a bit simpler stuff, if that basic tutorial suffices you.

I've written a couple Gradle plugins, one of them was to build and test programs in our custom DSL. This exposed me to all facets of Gradle, because whatever Gradle offers to compile Java, Kotlin, ... you will most likely use for another language as well. I could not have written these plugins without the Gradle documentation. But again, it's totally unrelated to Android development.

> But I am yet to encounter a developer who actually learned Gradle inside out just from using it and reading the documentation.

You just met him! ;)

Then why a (Turing-complete) programming language and not a config language? Simple: because a programming language gives you infinite more power than what any config system could ever provide. E.g. I could compare the origin IP, determine the country, and change the response based on that. And there are plenty of use cases like this which you cannot express in a config language.

From the first hit I found on Google:

* Fundamental researches mainly aim to answer the questions of why, what or how and they tend to contribute the pool of fundamental knowledge in the research area.

* Opposite to fundamental research is applied research that aims to solve specific problems, thus findings of applied research do have immediate practical implications.

I have the same experience on the battery: my pair is almost 3 years old and I can go about 2 days of work (~12 hours) before I have to charge them.

Not saying there's anything wrong here, for all I know it might be the same author on both projects. Taking a closer look, it might even be the case that tabler-icons is just a rebranding of FeatherIcons.