kaba0

50 ms·

751.
by kaba0 3y ago
It’s okay to do some allocations - it can be stack replaced, and even if it’s not, the cost is very negligible. The problem is mindless allocation, not allocation itself.
752.
by kaba0 3y ago
A gradle dependency is a finished artifact. It gets added to the classpath, what could it break? A gradle plugin could potentially break something, but a) you ain’t writing gradle plugins willy-nilly, b) if it’s a “big” one, it’s likely not
753.
by kaba0 3y ago
The type system would store it at compile time, while your type would only have it at runtime.
754.
by kaba0 3y ago
He is ignorant of it even before 2000, see their for loop fck up.
755.
by kaba0 3y ago
Languages are not created in a vacuum, or at least sane ones are not. Go failed to take into account the last 50 years of PL design, and it shows in its ridiculous number of shortcomings.
756.
by kaba0 3y ago
Lacks expressivity is likely what parent meant.
757.
by kaba0 3y ago
Just for an example: on the recent 1billion rows challenge, the top java contender takes only 2x as much time as a SIMD-optimized C one.
758.
by kaba0 3y ago
At least he knows something about a single other language! Honestly, I wasn’t sure about given the stupidity of go, and the warts it has.
759.
by kaba0 3y ago
More like java 1.2 sold in a worse package.
760.
by kaba0 3y ago
There are no area where java would fare worth than go.
761.
by kaba0 3y ago
That’s an absolutely bad take. Java is still very very conservative with every change, and they almost always have only local behaviors, so not knowing them still gives you complete understanding of a program. Like, records are a very easy
762.
by kaba0 3y ago
Those are safe. And it’s not like Go didn’t just copy nulls (plus even has shitty initialization problems now, e.g. with make!)
763.
by kaba0 3y ago
So, it’s Java 1.2, but worse. Cool contribution!
764.
by kaba0 3y ago
> Go was probably the key technology that migrated server-side software off Java bloatware to native containers Bloatware? That’s already an uninformed and loaded term, and Google still has and writes more Java than Go, if I’m not mistak
765.
by kaba0 3y ago
I mean, that’s android that is doing a shitload of stuff. But what other build tool could do the same thing as android does? There are not many contenders, and I don’t think they would fare much better. On the other side of mobile OSs, xcod
766.
by kaba0 3y ago
Then they fked up big time with the config file. Gradle has a correct view of the build graph, unlike maven. There are never a case (unless deliberately broken) where you have to clean build for correctness.
767.
by kaba0 3y ago
It is very rarely known, but I have to vouch for Mill. It is a very well thought out generic build tool written in scala - but it is pretty much as simple as a build tool can be, but not simpler. That is, it does parallelize tasks and prope
768.
by kaba0 3y ago
Unfortunately, maven can get into a state where it will fail to be correct without a clear step first. This never happens with gradle (unless you almost deliberately break something), and correctness is above all else. I often end up defend
769.
by kaba0 3y ago
Try Mill!
770.
by kaba0 3y ago
So what other general purpose build tool do you recommend/vouch for? I actually really like Mill, but it is very small still. I’m unaware of too many playing in the same categories as Gradle.
771.
by kaba0 3y ago
It has always been “an imperative code that outputs the declarative configuration that can be used for the build”. Which is a very reasonable thing to do, but unfortunately most people fail to understand that a println in the config file’s
772.
by kaba0 3y ago
There are not many alternatives that are truly general build tools (not limited to single language/repository, etc), and properly parallelize and cache. So, besides gradle and bazel, what else is there?
773.
by kaba0 3y ago
Build systems are a complex problem. Like, you can compare it to cargo/go’s build system etc, but these forget about 90% of the problem, and come up with a hard-coded for the happy-path rust/go project, with zero non-native depend
774.
by kaba0 3y ago
> It is definitely one of the most complex type systems due to interactions between nominal sub-typing and type classes That’s what I meant mostly. Though if I’m being honest, I’m not familiar with the implementation of either language’s
775.
by kaba0 3y ago
It is your own failure if you beat the tool over yourself, for not having learnt it.
776.
by kaba0 3y ago
Scala is a much different case, it has one of the most advanced type systems, many implicit scoping rules etc. Even a java change that might affect the scala codebase could result in a slow incremental build. Also, the build system may not
777.
by kaba0 3y ago
Yeah, I know. I believe it’s mostly the amount of LLVM IR that is the problem (e.g. each generic instantiation outputs by default a new copy of roughly the same code), isn’t it?
778.
by kaba0 3y ago
Then someone in your team failed learning the bare minimum to write a sane gradle file, and are putting imperative stuff into the configuration phase. For big projects, compiling only what’s necessary is a huge time win.
779.
by kaba0 3y ago
No, I would even go as far as to say that a naive, non-microbenchmark java program can often perform better than a naive, low-level language one.
780.
by kaba0 3y ago
What step are we talking about? Javac itself is absolutely on the same order of magnitude speed as Go per loc, while rust is significantly slower (which makes sense, the latter is a properly optimizing compiler with heavy static analysis, w

More ›