njitbew

> But what's the point in leaving available memory on the table if using it makes your program run faster? Efficient use of that resource wouldn't be to leave it untapped but to use it to speed up the program.

What’s the point of having a host with available memory? In today’s clouds, couldn’t you just downsize the host, and save on cost?

Sounds like a problem that the Mockito team created for themselves, and like a problem only they can solve.

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?

> and it feels bloated (Java!)

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.

Disclaimer: You guessed it, I work at Oracle.

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.

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.