6 ms·

> 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

> 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.

lionkor 3y ago
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.
_xivi 3y ago
> 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.
- dimitrios1 3y ago
  I believe it's mostly just a direct jab at C++. Almost every other language has fast or fast enough compilation speeds.
  - intelVISA 3y ago
    Rust sends its regards.
    - rockwotj 3y ago
      So does kotlin
      - andrekandre 3y ago
        swift too...
        streakfix 3y ago
        Javascript too
    - junon 3y ago
      Everyone says this but I've yet for it to ever actually be a problem.
      - earthling8118 3y ago
        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.
        junon 3y ago
        Right that's been my experience too. The initial build of dependencies takes a bit but that's never a problem for me personally.
  - anonymoushn 3y ago
    Any language that uses an LLVM backend is dog slow.
  - plugin-baby 3y ago
    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.
    - marginalia_nu 3y ago
      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.
  - rvense 3y ago
    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.)
    - easton 3y ago
      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.
  - winrid 3y ago
    C++ actually has pretty competitive compilation speeds, barring metaprogramming, up to a point.
- gleenn 3y ago
  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?
- dcow 3y ago
  productivity, or perceived productivity?
  - raincole 3y ago
    productivity.
omneity 3y ago
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.
valenterry 3y ago
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.
Night_Thastus 3y ago
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.
- dcow 3y ago
  > 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...
  - seer 3y ago
    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
  - 3y ago
phendrenad2 3y ago
You're all using languages that need to be compiled?
sixstringtheory 3y ago
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.
winrid 3y ago
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.
easeout 3y ago
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.

lionkor 3y ago

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.

_xivi 3y ago

> 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.

dimitrios1 3y ago
I believe it's mostly just a direct jab at C++. Almost every other language has fast or fast enough compilation speeds.
- intelVISA 3y ago
  Rust sends its regards.
  - rockwotj 3y ago
    So does kotlin
    - andrekandre 3y ago
      swift too...
      - streakfix 3y ago
        Javascript too
  - junon 3y ago
    Everyone says this but I've yet for it to ever actually be a problem.
    - earthling8118 3y ago
      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.
      - junon 3y ago
        Right that's been my experience too. The initial build of dependencies takes a bit but that's never a problem for me personally.
- anonymoushn 3y ago
  Any language that uses an LLVM backend is dog slow.
- plugin-baby 3y ago
  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.
  - marginalia_nu 3y ago
    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.
- rvense 3y ago
  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.)
  - easton 3y ago
    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.
- winrid 3y ago
  C++ actually has pretty competitive compilation speeds, barring metaprogramming, up to a point.
gleenn 3y ago
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?
dcow 3y ago
productivity, or perceived productivity?
- raincole 3y ago
  productivity.

omneity 3y ago

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.

valenterry 3y ago

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.

Night_Thastus 3y ago

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.

dcow 3y ago
> 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...
- seer 3y ago
  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
- 3y ago

phendrenad2 3y ago

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

sixstringtheory 3y ago

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.

winrid 3y ago

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.

easeout 3y ago

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.