I respect the maintainer's decision, but I don't understand the justification.
> 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?
> Horrible dev experience, no decent clients/libs, complex pricing, weird scaling in/out mechanism, slow, it only works well for well defined use-cases.
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?
Oracle Cloud only charges a fraction of want Google, Microsoft, and Amazon charge. Any idea how Oracle is able to keep the cost so low? Or are the others just inflating the price so customers don’t move to the competitor? In that case Oracle deserves a shout out for not applying these vendor lock-in practices.
ORMs could (and most do) provide some escape hatch, where you can write the query yourself and reuse the hydration layer, or reuse the query generator and customize the hydrator, or a combination. Or you can just bail out completely for the few performance critical queries.
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.
I don't understand the negativity in this thread about Oracle and the pricing model. GraalVM is an amazing piece of technology that enables many new applications. Oracle has the courage to invest heavily in this research, provides a community edition for free, and asks a very reasonable fee for the enterprise version. The pricing model is admittedly a bit complex, but from what I've been told it is a fairly common pricing model in this industry. And if you use the enterprise version in a way that is not allowed, you risk facing the consequences; no surprises there.
After upgrading my MacBook Pro 13" (2017) to Big Sur in Dec 2020 I had a similar experience. I use a 4k monitor and everything got super slow, fans started spinning, processes got throttled, and I could barely get any work done. I later did a fresh install of Catalina and everything was fast again.
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.
I know nothing about Android development with Gradle (or Android development in general, for that matter). I feel that is where a lot of negativity in this thread comes from. But then it's not per-se Gradle who is to blame; it's this specific use case of Gradle with Android which apparently is giving people a poor experience (e.g. lacking documentation).
> 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.
This is funny, because I have the complete opposite experience. Yes, it took me an afternoon to find my way around Gradle. But ever since I really appreciate their documentation. It is to the point, well written, contains code samples (which I believe are unit-tested, so they the code samples are always up-to-date), contains examples in both Groovy & Kotlin, and I could keep going on. A good entry point, for example, is Build Script Basics (https://docs.gradle.org/current/userguide/tutorial_using_tas...).
> But I am yet to encounter a developer who actually learned Gradle inside out just from using it and reading the documentation.
The problem is that it is super easy to modify a Gradle build scripts, but also super hard to get it right (e.g. understanding of configuration vs. execution phase, concept of configurations, task dependencies). As long as you don't touch the build script, Gradle is superior to Maven in _so_ many ways.
Why so negative? You don't _have_ to do all of that, but as a software engineer you are in the unique position in which you're able to do a bit of all of that _if you want to_. It's like saying: why should I do operations work when I'm a developer. But then DevOps became a thing and every developer was suddenly also an operations guy. Being able to pick up different roles is an extremely valuable skill, and you're limiting yourself if you're drawing an imaginary boundary between technical and non-technical things.
I don't understand what nginx has to do with this. nginx's language is just that: a language. If Lambda@Edge would support nginx language, you would still be invoking a lambda. But I'd must rather write some header rewriting code in, say, JavaScript than nginx's language.
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.
Without reading the article, I can imagine that listing the components of a technological product (i.e., an SBOM) is a _first step_ towards the goal of solving all those problems. Once you have a standardized way of communicating what a software product is made of, you can start thinking of automatically upgrading dependencies (Maven's pom.xml does this to some extent, and Dependabot and Renovatebot leverage this semi-standard to automatically upgrade your dependencies). If you take this one step (or two steps) further, you can start to automatically rebuild the code, automatically deploy the code, patch running systems, detect when CVEs are actively being abused, and so on. Basically, automate the heck out of this so that the "they just didn't do it" will not happen. And for automation, you need standards.
The distinction you're making is more about _fundamental_ research vs. _applied_ research, but it is research nevertheless.
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.
Are these "leather cups" you're talking about these "ear cushions" (https://www.bose.com/en_us/products/headphones/headphone_acc...)? If yes, then that's only 30-40$, which does not seem unreasonable for a product you use so intensively? I replaced mine after about 2 years. I remember the sound insulation being a _lot_ better afterwards.
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.
There seems to be a connection though. This project tabler/tabler-icons is part of Tabler, which features FeatherIcons: https://preview.tabler.io/icons.html.
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.