Hacker News Reader

Comment by stephendause | Hacker News Reader

> Use a language with good compile speeds.

This is an interesting suggestion to me. Honestly, I consider a lot of other things like type safety and ergonomics of the language before I think about compile speed if at all.

However, that's not to say it's irrelevant. Perhaps I should be thinking about it more. I did notice that they didn't suggest any particular language with this comment. Compile speed seems like a difficult thing to compare between languages in general, since it would be difficult to make a genuine apples to apples comparison.

View on HN

I think a fast compile is essential.

I've worked on projects with slow and fast compiles, and man, it's a completely different world. The way you think about problems and approach them, the way you approach adding new code, it's just completely different.

Slow compile times makes the entire process of adding, changing, or debugging the code slower. It makes it painful, frustrating, and more confusing. It's nonlinear. Doubling the time to compile a project can quadruple the time to solve problems, in my experience.

> Doubling the time to compile a project can quadruple the time to solve problems, in my experience.

My experience has been somewhat opposite.

Long compile times lead you to put more thought into your program, roughly (obviously I'm way over generalizing here, it's actually the language itself that causes this but I'm waving my hands and positing that there's a rough correlation between compile speeds and language formality). Slow compile times mean you're not thinking about how your problem is modeled formally and just kinda gluing things together and seeing what happens at runtime.

While quick compile times may get you a system that kinda works more quickly than a language with slow compile times, in my experience you have to iterate much much before the problem is truly solved. When I user slower languages I find myself iterating fewer times before the problem is usefully solved. Not to mention I spend far less time fixing bugs.

Maybe it's all a wash, but slow languages definitely do not result in a quadratic slowdown in productivity...

I dunno. I don't think this should be down-voted into the ground. But I think it's more nuanced.

Quick compile times may in some circumstances enable a sort of mentality of trial-and-error that I think is relatively common, but I don't think is a good approach to software development.

On the other hand, I don't think slow compile times are necessary to prevent this. Slow builds arguably more often lead to frustration and context switching. That isn't good either.

I think the best option is to have fast builds but also have enough discipline to not write code by trial and error.

The trade off here assumes a “barely working prototype” is undesirable and only the bug free end result is the goal.

Most projects I’ve worked on though, especially in their first few 100k lines of code didn’t really know exactly what problem are they trying to solve. Having something that kinda works in front if stakeholders / customers has been invaluable in actually getting the feedback and not wasting dev cycles on features nobody actually wanted.

Though granted “going back and doing things properly” has been as hard to achieve as “have complete requirements upfront”, so what do I know :-D

We should go back to punch cards, then. We'll obviously have much higher quality software.

You joke, but bugs in your punchcard program were a royal PITA, so people spent more time making sure they were correct before going through the work of punching them out. I've heard this from a first hand source.

Quality is not lack of bugs. That's a component, maybe.

Yep, but they still had bugs, and often the minimum turn-around time was 24 hours. So it does not sound like a net positive

> I consider a lot of other things like type safety and ergonomics of the language before I think about compile speed if at all

I believe the good compile speed is hinting at having shorter feedback loops in your workflow, and how it can significantly boost your productivity

It's something you'll do often and can have hidden costs. Especially with cases when it takes half an hour to build a software.

The number of engineers I've met that don't know how to run a single test or single test file and wait minutes for 1000's of tests to run is mind-boggling to me. Like, how do you get anything done?

productivity, or perceived productivity?

productivity.

I believe it's mostly just a direct jab at C++. Almost every other language has fast or fast enough compilation speeds.

Scala can be very slow.

I’ve also worked on Java / Spring Boot projects that seem to take 10s of seconds to compile, and even longer to start up.

And TypeScript too.

I suspect the latter two have simple options which could improve things significantly, but I haven’t dug in.

Java is very much what you make of it. Spring Boot tends to pull in everything and the kitchen sink, and the atrocious build and start times are a fairly logical consequence.

Vanilla Java can be very quick to start and build, especially if you do incremental builds.

In my search engine project which is ~50kloc I have incremental builds that can be as fast as 1-2 seconds including running all pertinent tests[1], and the start time for the stuff that doesn't like populate an 12 Gb hashmap in memory upon start-up is also single digit seconds.

[1] A clean rebuild is 37 seconds; 108 seconds with a full suite of tests. That's fairly tolerable IMO. I've horror stories of Java builds that have had compile times anywhere between 15 and 45 minutes.

Rust sends its regards.

Everyone says this but I've yet for it to ever actually be a problem.

That's because it isn't unless you have a very exceptional case or maybe you make a mega-crate. I was rocking a severely outdated processor and it was slightly annoying, but not that bad at all. And once the dependencies are built it was a non-issue. With a more modern CPU the times are miniscule.

Right that's been my experience too. The initial build of dependencies takes a bit but that's never a problem for me personally.

So does kotlin

swift too...

Javascript too

Any language that uses an LLVM backend is dog slow.

C++ actually has pretty competitive compilation speeds, barring metaprogramming, up to a point.

The Typescript/Angular project I dayjob on sometimes takes minutes to compile, depending on whatever optimization settings the last Angular update has changed/messed up. (The compilation also frequently spins out of control until it OOMs.)

Hah. We have shared build boxes at work, which are EC2s that are too small to share anyway, and if two Angular builds run on the same box at once then its guaranteed that the machine is going to die. It's very interesting how things start to fail strangely when the machine is out of RAM.

There’s also modularization to compartmentalize recompilation, reducing the overall time to rebuild for any given change. CI can cache compiled modules.

This then kicks the can down the road to the linker, and there’s been some work in this area as well with projects like mold.

The fact is the complexity in most valuable systems is interacting with other external systems.

Your system can be as type safe as it wants. It will never be type safe when tied to the systems of other companies, no matter what they say, or how they say their apis are supposed to work (assuming you have documented apis at all).

Being able to iterate quickly and test those connections is far more valuable to most businesses. At a certain scale, it probably flips, but at that point you're a huge company.

I'd say, use a toolchain that gives you rapid iteration to the point that you try to keep up with it, rather than the other way around. For instance a hot reloading workflow has been common for web apps for some years, but in native mobile we've only recently gained the capability via the preview canvas for SwiftUI. That makes a huge difference even though Swift is a big step down in compile speed from its predecessor.

Yeah I agree. I think what matters more is IDE speed (which includes syntax and partial compile to some degree). Then comes incremental compile which should be fast or at least exist. and then comes compiletimes in general.

Also: compiletimes are not a property of just languages. It also depends how you use them. And languages with few guards and guarantees (like Go) of course compile faster - but you pay the price later.

I often spend hours of writing code without ever compiling - once you are familiar with the language and how the compiler behaves, that should be the norm.

When I then compile, its okay if it takes 10 seconds or 10 minutes.

It might be that you didn’t encounter this as a problem before.

In its earlier days, changing a single character in a typescript codebase implied a trip to the kitchen.

Now TS compilation is decently fast but intellisense became the bottleneck.

You're all using languages that need to be compiled?

Reply on news.ycombinator.com