Scarf has moved away from Haskell

Re:Scarf has moved away from Haskell by Tarean on Friday July 10, 2026 @10:34AM (#48860577)

Java can also have 15+ minute cold compiles on large projects if you kill all caches. It's less bad on smaller codebases because you don't have to recompile dependencies if you target a bytecode vm, but if you always gate feedback on a cold compile in a fresh VM you just aren't gonna beat an interpreted language

But I'd look at people a bit oddly if they said: 'We didn't want to set up CI caching and compiled languages took 30 minutes per run so we changed our entire codebase to python'.

Maybe it makes sense for them, and caching across dynamically spawned VM's is admittedly a harder problem which most build systems aren't great at, but still. I can easily believe that getting build caching to be reliable would be a lot of work, but is it more work than a full rewrite of a significant codebase?

[ Parent | on HN ]

Re:Scarf has moved away from Haskell by pjmlp on Friday July 10, 2026 @11:14AM (#48861090)

Additionally in modern Java there are even the options of AOT and JIT caches, which can be reused across runs.

Or if staying on Linux, JVM snapshots.

[ Parent | on HN ]

Re:Scarf has moved away from Haskell by hunterpayne on Friday July 10, 2026 @10:06PM (#48867866)

javac doesn't really do a whole lot. Consequently, whatever compile time you are complaining about would be worse with any other compiled language. Most optimization work in Java happens at runtime.

[ Parent | on HN ]

Re:Scarf has moved away from Haskell by pjmlp on Saturday July 11, 2026 @01:15AM (#48868976)

First of all I am not complaining about anything.

Secondly, there are several ways how Java source code becomes machine code, depending on which JVM and JDK is being used, not taking into account the ART cousin.

[ Parent | on HN ]