I am unsure why people feel the need to say this about Gradle. If you aren't doing anything fancy, the most you will touch is the repositories and dependencies block of your build script, perhaps add publishing or shadow plugins and configure them accordingly but that has never been simpler than it is now. Gradle breaks when you feel the need to unnecessarily update things like the wrapper version or plugins without considering the implications that has. Wrapper is bundled in so you don't have to try and make a build script work with whatever version you might have installed on your system if you have any, toolchain resolution makes it so you don't even need to install an appropriate JDK version as it does that for you.
If the build script being a DSL is the issue, they're even experimenting around declarative gradle scripts [0], which is going to be nice for people used to something like maven.
So now there will be Kotlin DSL, Groovy DSL and declarative DSL, spread out over up to five files in the project root. Gradle is like C++, trying to climb out of it's complexity hole by digging deeper every new version.
The problem with Gradle is that it never had a clear philosophy to begin with. It's trying to be everything to everybody, changes best practices every year and has enough features that the project at hand could entirely be built out of Gradle scripts itself.
And oh, it still requires an update to run everytime a new JDK is released even though the SDK is the most backward compatible thing ever written.
I personally never had to do a clean install, and thought this is being perpetuted due to a mixture of habit and paranoia.
In any case, what are the proposed benefits of the "kotilization"? I tried it about a year ago but realized that it's just a syntax level-wrapper around the same old DSL underneath. In the end, I still viewed it as an ill-described DSL with a massive learning curve outside of happy-paths.
if you want to an online java decompiler for a quick analysis, I recommend https://slicer.run/, it has a sleek UI and provides support for a variety of decompilers (including the likes of Vineflower, CFR, JASM, Procyon). For more in-depth analysis, https://github.com/Col-E/Recaf is probably my first choice
Stuart Marks and Nicolai Parlog recently had a discussion about checked exceptions in the Java channel [0]. In short, while they mentioned that there are certainly some things to improve about checked exceptions, like the confusing hierarchy as well as the boilerplate-y way of handling them, they're not necessarily a failed concept. I do hope they get to work on them in the near future.
They are absolutely failed concept in Java. Every first popular library uses unchecked exceptions, including famous Spring. Java streams API does not support checked exceptions. Even Java standard library nowadays includes "UncheckedIOException". Kotlin, Scala: both languages grown from JVM and do not support checked exceptions.
Spring has a special error handling strategy where the whole request is allowed to fail, punting error handling off to the caller.
A lot of code that throws checked exceptions is simply dangerous to use with Java streams because the execution order of stream operation is not obvious and possibly non-deterministic. For this reason, streams were never intended to also handle errors. Reactive frameworks are much better at that.
The UncheckedIOException is for situations where you really cannot throw a checked exceptions, such as inside an iterator. Which might lead to ugly surprises for the API user;
> A lot of code that throws checked exceptions is simply dangerous to use with Java streams because the execution order of stream operation is not obvious and possibly non-deterministic.
From the type system PoV, they could have just written something like `interface Runnable<X> { void run() throws X; }` and now `forEach` would have been written like `<X> void forEach(Runnable<X> r) throws X`. And repeat that for all stream operations, promoting `X` everywhere, so if your mapper function throws SQLException, the whole pipeline will throw it.
It even works today with some limitation (there's no way for `X` to get value of `SQLException|IOException` union type), but with some generic improvements it could work.
But they decided to not touch this issue at all. So now people will fool compiler with their tricks to throw checked exceptions like unchecked (or just wrap them with UncheckedXxxException everywhere, I prefer that approach).
At the risk of repeating myself: streams were simply never designed with error handling in mind. Aborting everything at the first error is just the most simplistic error handling strategy. Reactive streams frameworks should be preferred for this.
> The counter to that argument is that it's creating an adverse effect on your most
> profitable customers, with an incentive to move to offerings that don't have free tiers (or where the free tiers are not considerably affecting your own costs).
> If your free tier is so lucrative that you need to 25x the cost, then your free tier is > too expansive and you need to tone it down until the economics make sense.
It does make sense, though. That's how almost every subsidized system works, and the benefit applies for everyone until they scale to a point where they are not legible for it. It does suck for the pool of people that just began paying the actual price of the service instead of the subsidized one, and certainly more so if they're not actually getting profit from it but then again, it isn't like they weren't benefitting from the price up to that point, otherwise they wouldn't have chosen it. Luckily enough, as far as databases go, there's a gazillion options to choose from and experiences like this are invaluable when it comes to picking one with a pricing model that fits the scaling requirements of a given project, and not only the technical merits.
Also as a side rant, I honestly don't think "projects of love" are a good counter argument to anything. They're clearly not of love because otherwise they would find a way to make them profitable. Most people are either lazy to, or lack the knowledge of how to turn their hobby into a marketable thing. Which is fine, nobody wants to deal with business when it comes to their hobbies, but one can't have it both ways. Either your hobby project gets successful and you find ways to cover its expenses, or you realize that your hobby project needs to be kept just a hobby project.
> Also as a side rant, I honestly don't think "projects of love" are a good counter argument to anything. They're clearly not of love because otherwise they would find a way to make them profitable.
I appreciate the... tough love here, and also acknowledge that 'doing it for love' is ambiguous. But I strongly disagree that declining to make something profitable indicates that it's not out of love.
To clarify my own situation, it's more out of wanting to share knowledge with the world and build a community. It's a very popular site, ubiquitous in its niche, but that's about as much as I'll divulge.
I'll grant that we've been benefitting from the subsidy/hook up to now. But I'll also add the wrinkle that a substantial increase in bandwidth is due to AI harvesters. They are becoming an existential threat to projects like these.
> But I'll also add the wrinkle that a substantial increase in bandwidth is due to AI harvesters. They are becoming an existential threat to projects like these.
Hmmm. I looked at one site with a fair amount of traffic that I have access to and the user agents that identified as AI crawlers were not significant in terms of traffic. Low single digits.
Curious what percentage of AI crawlers your site is seeing?
I seldom use it myself, but I frequently see people sharing compiler explorer snippets to compare generated assembly on discord conversations about LLVM in just about any native language discord (but mainly the Rust official one), which may sound like a rare occasion, but it happens more often than you'd think. My impression is that it is definitely in the thousands, but it being a service that I've only seen used for quick comparisons rather than in-depth analysis, I can't tell whether it is much more than that
it isn't Ghibli style in particular, just any style as 4o image gen is much better at maintaining a particular art style, the ghibli ones just stand out due to one tweet that blew up and people followed along
That makes sense. Although previous model's image gen wont bad as well with Ghibli style. I guess "maintaining a particular art style" is the point here. Thank You.
Well, for starters it is just a whole lot less work and money to distribute and maintain binaries up from the distributers' side, for the developers it comes down to a lower-barrier of entry to not have to adjust their workflow to whatever x platform may demand for building on their servers and in the end that gives the users more choices to work with. Of course, this is all in a perfect world where the chain of trust isn't broken so easily, which isn't an easy feat but given platforms like Windows thrive in spite of it, it is probably not as bad as many people may think.
All of that said, not particularly speaking for OpenAPK here, given their motives seems rather unclear to me. If I am to be charitable, I guess they're just trying to provide a different platform than f-droid for discoverability, but for whatever reason they seem to be marketing the distribution-side of things more which is just odd to me, but alas.
> given platforms like Windows thrive in spite of it, it is probably not as bad as many people may think.
There is a lot of extra work done behind the scenes to "thrive in spite of it". Windows Defender (built into Windows after XP) has to periodically download updated virus definitions and always scans programs for potential malware, and still can't catch them all.
The funny thing about Java is that while its design is to be entirely nominally typed, the way it is implemented in the JVM is compatible with structural typing, but there are artificial limitations set to follow the intended design (though of course, if one were to disable these limitations then modeled type safety goes out of the window as Java was simply not designed to be used that way). One community which takes advantage of this fact is the Minecraft modding space, as it is the basis[1] of how modding platforms like Fabric work.
Well, in the case of Samsung, I imagine they would rather not want to in order to promote their Z Flip series instead. More compact than any Mini version would potentially be. Though I guess for the people who like their phones to be able to fit in their hand, it doesn't make much of a difference.
If the build script being a DSL is the issue, they're even experimenting around declarative gradle scripts [0], which is going to be nice for people used to something like maven.
0: https://declarative.gradle.org/
reply