Ooh fun, Advent of Code chaser!
A fair comparison between languages should include the make and build times. I haven't used Java / Maven for years, and I'm reminded why, heading into minute 2 of downloads for './mvnw clean verify'.
A fair comparison between languages should include the make and build times. I haven't used Java / Maven for years, and I'm reminded why, heading into minute 2 of downloads for './mvnw clean verify'.
(Also, gradle is faster as a build tool for incremental compilation)
> gradle is faster as a build tool for incremental compilation
Implicit:
> …than it is building from scratch, where it needs to download lots of stuff
I mean, yes, saying Java builds are fast does seem a bit “rolls eyes, yes technically by loc when the compiler is actually running” …but, ^_^! let’s not start banging on about how great cargo/rust compile times are… they’re really terrible once procedural macros are used, or sys dependencies invoke some heinous c dependency build like autoconf and lots of crates do… and there’s still a subpar incremental compilation story.
So, you know. Eh. Live and let live. Gradle isn’t that bad.
As for precedural macros - yes they can be slow to compile but so are Java annotation processors.
In my experience, java annotations gets processed very fast.
Well, that's a bit of a stretch. It is definitely one of the most complex type systems due to interactions between nominal sub-typing and type classes which is a bit hairy. But in terms of what this type system can express or prove, it's both inferior (cannot express lifetimes or exclusive access) and superior (HKTs, path dependent types) to Rust in some aspects. Let's say they are close.
That’s what I meant mostly. Though if I’m being honest, I’m not familiar with the implementation of either language’s type system.
300K LOC Java should be done within ~1.5 minutes flat from zero. Can be even faster if you are running maven daemon for example. Or even within ~30 seconds if everything is within one module and javac is only invoked once.
Gradle with a daemon is also pretty fast, you are just probably used to some complex project with hundreds of dependencies and compare it to a cargo file with a single dependency.
Not really when it has to run on a cold JVM. And before it warms up, it’s already done.
Then you are in territory of keeping the compiler process between the runs, but that is a memory hog and also not always realiable (gradle often decides to run a fresh daemon for whatever reason).
So theoretically, in lab conditions yes, in practice no.
> while rust is significantly slower
Everybody repeats that but there is surprisingly little evidence in form of benchmarks. I can see rustic compiles over 50k Loc per second on average on my M2, which is roughly the same order of magnitude as Java. And checking without building is faster.
Wiki citation for good measures https://en.wikipedia.org/wiki/Javac.
Maybe you're thinking of Hotspot, which is written in C++.
I've yet to see a project where Gradle daemon a) does anything useful and b) is acutally used by gradle itself (instead of seemingly doing everything from scratch, no idea what it does in the seconds it takes for it to start up).
Also my experience.
Only using Gradle deamon does not help making a multi-project setup much faster. You also have to enable build cache, configuration cache and configure on demand with `--configuration-cache --configure-on-demand` and hope nobody in the project breaks the ability for Gradle to use these caches. But then it still took at least 10 seconds to build and start my services (and that's with incremental builds, like you changed one line of code after the first slow build). I spend two days and more after release to speed this stuff up, before it was 30 seconds sometimes 60 seconds.
And the protobuf Gradle plugin sometimes did not update the generated code, so you had force-delete the files on every build. And then other stuff in the caches broke and you had to delete `.gradle` directory and sometimes even the `~/.gradle` directory. And sometimes the Gralde daemon hangs so you have to force it to stop with `--stop.
Go build, deno and bun are so much more reliable and faster. Something that was surprisingly fast was using the Gradle setup with skaffolding. Java hot code swapping is very fast.
I have no idea what gradle and its daemon do except spending orders of magnitude more time starting up than running the actual build.
You're much better off running javac directly. Then it's fast.
For big projects, compiling only what’s necessary is a huge time win.
Then someone in over 15 years and 8 versions gradle failed to make a system that doesn't require "learning to write sane gradle files" to make sure that it's only two orders of magnitude and not five orders of magnitude slower than it can be.
> and are putting imperative stuff into the configuration phase
Has nothing to do with the slowness that is gradle.
> For big projects, compiling only what’s necessary is a huge time win.
It is, and no one is arguing with that
- in 15 years is still slow by default
- in 15 years could not acquire any sensible defaults that shouldn't need extra work to configure
- is written in an esoteric language with next to zero tools to debug and introspect
- randomly changes and moves thing around every couple of years for no discernible reason and making zero impact on reducing its slowness
- has no configuration specification to speak of because the config is written in that same esoteric programming language
And its zealots blame its failures on its users
Meanwhile, there are only a couple, truly general build systems, all of them quite complex — as you can’t get away with less. Gradle and bazel are pretty much the only truly generic build systems (I’m sure there are a couple more, but not many). You can actually compile a mixed java, c++, whatever project with gradle, for example, just fine, with proper parallelism, caching, etc.
As for your points:
> in 15 years is still slow by default
Absolutely false. A 3-4 lines gradle build file for java will be fast, and correctly parallelize and maximally utilize previously built artifacts.
> in 15 years could not acquire any sensible defaults that shouldn't need extra work to configure
It’s literally 4 lines for a minimal project, maybe even less. I’m getting the feeling that you have zero idea about what you talk about.
> is written in an esoteric language with next to zero tools to debug and introspect
I somewhat agree, though nowadays kotlin is also an alternative with strong typing, proper auto-complete, the only trade off is a tiny bit slower first compile of the config file. Also, both could/can be debugged by a normal java debugger.
> randomly changes and moves thing around every couple of years for no discernible reason
There is some truth to this. But the speed has definitely improved.
> has no configuration specification
Kotlin is statically typed. Also, the API has okayish documentation, people just like to copy-paste everything and wonder why it fails. You wouldn’t be able to fly a plane either from watching 3 sitcoms showing a cockpit, would you?
I've never seen this on any project that utilizes gradle. Every time, without fail, it's a multi-second startup of gradle that eventually invokes something that is actually fast: javac.
> I’m getting the feeling that you have zero idea about what you talk about.
Only 7 years dealing with java projects, both simple and complex
>> has no configuration specification
> Kotlin is statically typed.
Kotlin being statically typed has literally nothing to do with a specification.
Becuase Gradle doesn't have a configuration. It has a Groovy/Kotlin module that grew organically, haphazardly and without any long term plans. So writing gradle configuration is akin to reverse-engineering what the authors intended to do with a particular piece of code or API.
> Also, the API has okayish documentation
"okayish" is a synonim for bad. You'd think that a 15-year project in its 8th major version would have excellent API documentation
> people just like to copy-paste everything and wonder why it fails. You wouldn’t be able to fly a plane either from watching 3 sitcoms
So, a project with no specification to speak of, with "okayish" API that is slow as molasses by default out of the gate [1] keeps blaming its users for its own failure because somehow it's a plane, and not a glorified overengineered Makefile.
[1] A reminder, if you will, that gradle managed to come up with caching configs to speed up its startup time only in version 8, after 15 years of development.
But for time being maven is way easier to configure and understand.
Literally no one complaining about gradle being slow is doing that. Allmost all of gradle's problems come not from people using it, but from Gradle itself.
I mean, you said it yourself: in 15 years the state of their API docs is "okayish". But somehow people are still expected to make sense of this shit because apparently it's a plane? But planes famously have extensive documentation, and procedures, and decades of expertise available. Exactly unlike gradle.
I actually really like Mill, but it is very small still. I’m unaware of too many playing in the same categories as Gradle.
I know of at least one project who just wrote everything in Python because current build tools invariably suck: https://tonsky.me/blog/python-build/
So, besides gradle and bazel, what else is there?
if you do that, you should also include programming time, and divide both by the number of runs the code will have over its lifetime. Also add an appropriate fraction of the time needed to learn to program.
In such a challenge, that likely would make a very naive version win.
Apart from being impractical, I think that would be against the idea behind this challenge.
Not if you give a realistic number for an actual database of this scale. Tens of hours of dev time isn't much after you divide it by a few million.
“I discard cache and it is so slow, aarghhh”
> No external dependencies may be used
But the real meaning is that you're not allowed to use external libraries, rather than build tool related dependency.