Hacker News new | past | comments | ask | show | jobs | submit | more lihaoyi's comments login

Notably, the benchmarks I provide are all single-core. You can get more if you modularize the project and spread out the load over multiple cores, and some of the other pages linked from the OP go into more detail


Notably all the benchmarks you provide are synthetic and not achievable by developers. I more care about real benchmarks for real developers, that they can see in their daily working lifes.


I don't think anyone checks their artifact signatures. I've changed signatures several times over the past few years (every time I get a new laptop I forget to copy over my keys) and haven't heard a peep from anyone using my open source libraries who actually noticed the change


We notice and costs several hours per month to handle. A malicious party can slip through, single contributor software is classified as a high risk but XZ utils were not classified as such so we would have missed the Jia Tan incident.


Don't worry, I wrote this article about Java but my day-to-day work is Scala. We're lucky if we can crack 4,000 lines-per-second-per-core on my pretty vanilla Scala projects x_x


I feel the pain, I've started a startup on Scala (and some years later successfully sold it), but compilation speed and 20 lines type constraint errors where my biggest problems (but I never forget that it enabled us to scale the company and sell it :-) - but if a programming language spawns consulting companies that only help with speeding up compile times, that is a bad sign.

Though when working on a 2M+ LOC Java project 15 years ago, we also spent a lot of money on very fast RAID hard drives in developer machines to speed up compilation. JRebel was a huge relief back then.


The benchmarks in the article do use the Gradle daemon, but not the Maven one, mostly because mvnd isn't the default.

For Gradle, if you turn off the gradle daemon, it gets even slower than the numbers presented going from 4+ seconds to 10+ seconds per compile:

    lihaoyi mockito$ git diff
    diff --git a/gradle.properties b/gradle.properties
    index 377b887db..3336085e7 100644
    --- a/gradle.properties
    +++ b/gradle.properties
    @@ -1,4 +1,4 @@
    -org.gradle.daemon=true
    +org.gradle.daemon=false
     org.gradle.parallel=true
     org.gradle.caching=true
     org.gradle.jvmargs=-Xmx2048m -Dfile.encoding=UTF-8 \

    lihaoyi mockito$ ./gradlew clean; time ./gradlew :classes --no-build-cache
    10.446
    10.230
    10.268


Our relatively complex multi module Gradle takes 30s just to configure. That rarely happens though as things are usually coming from a cache.


Oh wow. That's... something. :)


Author here, hope people find this article interesting!


"From this study we can see the paradox: the Java compiler is blazing fast, while Java build tools are dreadfully slow."

Hi, nice article! I wholeheartedly agree with the conclusion after 10 years of fighting with maven for performance gains (that I always measured in minutes not seconds).

Slow feedback cycle is the root of all evil.


I'd love to see Bazel added to the comparison.


Python's truthiness behavior was the trigger for one of my worst ever bugs early in my career, which not only pulled in senior engineering but also marketing/comms and legal to help sort out the mess. Not a fan!


I think this needs more explanation to know if this is a good argument or not.


Keep in mind that truthiness comes from __bool__ and is overridable, so separate from Python itself, a lot of library authors have made questionable decisions here. A perennial contender is https://github.com/psf/requests/issues/2002.


You know you're going to need to provide us with a little snippet demonstrating this behavior now, right?


I went and dug up the original code that caused an issue. Here it is:

https://github.com/python/cpython/blob/v2.7.1/Lib/cgi.py#L60...

Python's std lib `cgi.FieldStorage` object was falsy if it did not define any headers, even if it contained file data.

Thus my conditional trying to check whether a file was being uploaded "if request.field_storage" was going through the False branch when files were being uploaded but only in certain header-free scenarios not covered by automated and manual testing. This resulted in us dropping user data on the floor and losing uploaded files for a very large number of users before we realized and shut it off

The other sibling post contains another example where people may be confused, and Google pulls up others. But this is the concrete case that caused us to send out a hundred thousand apology emails to affected customers after losing their files


I persoanlly found the syntax weird and the IDE support poor when i was playing with it in 2013

Both of these are surprising to me. It is an indentation language, similar to Python which I love. And it was by Microsoft, which makes Visual Studio which I also loved

Yet I found the syntax a lot odder than Python: multiple ways to call methods (C# style and Ocaml style), a wide selection of strange brackets, `.[i]` for array lookup instead of `[i]` (i think they fixed this eventually). And despite Visual Studio being great for C#, its support for F# wasnt up to scratch

I ended up settling on Scala, which is semantically very similar, but with an easier syntax (not perfect, but better) and decent Intellij suppory (again, nowhere near perfext!)


The biggest difference happened between 2020 and 2024. I encourage you to give it a try - F# support with Ionide in VS Code is excellent.

There is no other platform like .NET in capability to cover both high and low level scenarios.


f# has improved a ton in the last decade. Rider and Ionide are both good environments to work on f# code in.


They are bounties, paid on completion at my discretion. Anyone worldwide who can receive international wire transfers can receive payment for them. I've paid out to people in quite a variety of places, from US to Europe to Japan to India to Africa


Maven is actually pretty behind in terms of JVM dependency resolution. Mill uses Coursier, same as my last company did, and when my last company switched from Maven to Coursier we saw a 2 order of magnitude speedup, with resolution commands that used to take 30min finish in a few seconds to give the exact same artifacts and versions.

I actually have no idea why these other resolvers are so slow, or why Coursier is so fast, but this slowness is very much a "maven" or "gradle" thing rather than a "jvm" thing. And Mill using coursier does significantly better!


Mill uses the same daemon design as Gradle and mvnd. You do hit edge cases occasionally, but overall it works great


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: