6 ms·

I guess I'm in the thought camp (a diminishingly small camp, if HN is any measure) that compile times don't matter. If you want short compile times, use interpr

by junon 3y ago

I guess I'm in the thought camp (a diminishingly small camp, if HN is any measure) that compile times don't matter. If you want short compile times, use interpreted languages. I appreciate the checks, validation, and optimization a compiler gives, and Rust's cuts down on total development time because of the extensive checks it performs. I remember a time where C++ projects took hours to build that today only take a few minutes. Perhaps that's an assist when 'dealing' with compilation times. I also don't think tests should be blazing fast. I'd rather correct tests than fast tests, just like I'd rather a thorough compilation over a fast one. Anecdotally, even with a project that has an upwards of 50 dependencies, many of them *-sys crates, I've never thought that compilation times were that bad. Speaking of interpreted languages, Javascript projects have historically taken exponentially longer to compile (looking at you, Meteor) and are rarely incremental. That's not to say "don't optimize things" of course but there are seemingly many people very upset or critical of Rust's compile times that I've never fully understood.

Ygg2 3y ago
I hear ya. But people are vocal about those. And thus Rust optimized those. Others (a game dev acquaintance) complains about debug performance being abysmal. At the end of the day, what people are vocal and more importantly willing to sink their time/money into will decide what happens.
izacus 3y ago
What's the biggest, oldest project you've ever worked on?
- junon 3y ago
  A tie between the Linux kernel and LLVM (specifically Clang). Also making game engines gets pretty hefty quite quickly. That's just open source work though. I've worked on larger systems at some Big Tech that were unwieldy, too.
  - izacus 3y ago
    And at no point were you bothered by the timewaste C/C++ compiling (and especially, unavoidable linking!) brings to your work process, CI process and general ability to quickly debug and iterate on a hard problem?
    - pertymcpert 3y ago
      It depends on the problem. For some problems where you’re spending time mostly thinking, and relatively little time actually typing code, the compile times don’t really matter that much. For LLVM for example, with clangd configured to do code completion and syntax checking in the editor, you don’t really have to do as many build/test cycles. That said, I think fast compile times are important for the other use cases.
dllthomas 3y ago
I use rust because of the value it brings for the reasons you say and for others, but it would bring me even more value if it built faster. Compile times absolutely matter; how they trade off against other things will depend on the particular project.
papruapap 3y ago
Go also have fast compilation times btw (:
- Ygg2 3y ago
  And a GC.
- mfrw 3y ago
  I don't think the compile times of Go can be even compared with Rust or any major compiled language. It does compile extremely quickly; Rust on the other end lies completely opposite on that spectrum IMO. Although, both languages are "modern", both have their pros & cons. Although this may sound like a pink elephant, but I would really want something that has the guard-rails, expresiveness & performance of Rust with the simplicity & compile-time speed of Go.
  - 3836293648 3y ago
    Go is not modern and has never been modern. It's an old language that just happened to be designed and implemented recently.
    - yawaramin 3y ago
      You are looking at only the language, you should also evaluate the toolchain and runtime. Go has a toolchain that most other languages (including Rust) can only dream of.
  - yawaramin 3y ago
    > Although this may sound like a pink elephant, but I would really want something that has the guard-rails, expresiveness & performance of Rust with the simplicity & compile-time speed of Go. This is basically OCaml.
    - mfrw 3y ago
      Sure, thanks for the tip. I will take a look :)
chaxor 3y ago
I am a bit surprised about this as well, since my perspective on a Rust comparison to C++, one of the more noticable issues is the extra verbosity rather than compile time. You're right about switching to interpreted languages for this reason as well. Python is so incredibly simple to write, and doesn't have any compile time at all. I think a better trade off is a language that has a long compile time, is very fast and secure, but has simpler syntax. Effectively a rust based language with simpler syntax. I recognize some of these exist, but they need to be popular enough to use as well.
oreilles 3y ago
I don't understand this take. Correct and fast are absolutely not mutually exclusive, wether it apply to tests or compilation. The rust compiler is not slow because of all the checks it performs, it's slow because of the way those checks are implemented. > If you want short compile times, use interpreted languages Interpreted languages are not compiled, so this sentence doesn't make sense.
- diarrhea 3y ago
  > Interpreted languages are not compiled, so this sentence doesn't make sense. Usually it's a moot point, but in the context of the post it isn't. Python, Lua and JavaScript are compiled to bytecode / intermediate representations. That's compilation, but usually not mentioned, as it's so fast. However, in this context, that speed is the exact point. Use interpreted languages if compilation times (or lack thereof) are a concern! The lines are blurry though. C# and Java are also interpreted languages (compiled to intermediate representation, then executed on the language runtime aka VM; possibly JITed to native machine code), but no one calls them that.
  - oreilles 3y ago
    There is a very clear difference between compilation and interpretation: in scripting languages, a statement does not depend on the following ones to be executed, meaning that the code can just be read through. Compilation is different because the binary produced need to include the whole program, therefore the whole code has to be read and analyzed before the bytecode can be produced. Compile litterally means "group together". So compilation time obviously only applies to compiled languages. Saying that the compilation time is not a concern to you and shouldn't be to anyone is also very short sighted. I'm pretty confident that you would consider it to be a problem if a "Hello world" took a week to compile. Maybe you meant "Compilation is fast enough for me", which is fine, but there is no reason why your speed expectation should be more legitimate that anyone else's.
    - naikrovek 3y ago
      took the words right out of my mouth. compilation speed matters. it matters to some more than others, obviously, but it absolutely matters, and to some it matters a great deal.
lordnacho 3y ago
I wouldn't say compile time doesn't matter, just that it's highly non-linear. The breaking points are: - You can restart the program as you're typing it. I've been looking at Elixir lately, and if I find a bug I can fix it and immediately look at a page that's got my change. - You can compile it and it will be done before you async to something else, so you aren't waiting long. Typically you also have a good idea as to whether it will compile. - You hit compile, and you know you have to find something else to do. Sometimes it will break when you're doing this other thing and the time lost is even greater. I think this used to be normal in the punch-card era.
diarrhea 3y ago
> Rust's cuts down on total development time because of the extensive checks it performs Plus, there's rust-analyzer/LSP. It works in real-time, and catches basically everything one might care about, no compiler needed. It's kind of like a static interpreter. My use cases are modest, but so far, once r-a was happy, the compiler was as well. Mileage might vary when using crate features, possibly? Inactive features are (until Rust 1.72 at least) invisible to the compiler so issues might arise only at compile-time there. > I'd rather correct tests than fast tests, just like I'd rather a thorough compilation over a fast one. The first one is a false dichotomy though. It's not like people write fast but incorrect tests whenever given a keyboard.
- _ahxg 3y ago
  You can enable optional features on Rust analyser. For example, to enable ssr Leptos feature on VSCode, you'd need to create a .vscode/settings file: { "rust-analyzer.cargo.features": [ "ssr" ] } Currently, though, you cannot enable the incompatible "hydrate" feature at the same time, sadly.
stephc_int13 3y ago
A lot of us realized over the years that compilation time was a productivity killer. The workflow can be adapted to slow compilation, obviously, with some discipline and a less iterative process. But the ideal "flow" for many coders is attained with zero interruptions and being able to write-compile-test in a seamless fashion. I think that the success of interpreters in many fields is related to this. Modern compilers should maybe be split in two, a fast compile/slowish code/loose tests version and a "checks+release" one. We have incredibly fast computers, instant compilation is feasible.
- amenghra 3y ago
  We could do day-to-day Rust/C++/any compiled language related development with an interpreter/JIT and then compile the code once a PR is ready and the code hits CI/CD or gets deployed. The "instant" runtime doesn't even need to have the exact same behavior -- it can be 99% accurate and still be very useful.
  - rewmie 3y ago
    Why would anyone subject himself to that? All mainstream build systems already support incremental builds, and in some cases it's even possible to leverage compiler cache to further shave down the time it takes to rebuild a project. Breaking down a monolithic project into submodules is all it takes to shave off a big chunk of time from a build.
    - amenghra 3y ago
      Imagine being able to set a breakpoint in a function, change something and ask the debugger to “travel” back in time and pretend the code was always what it’s been changed to. It’s something some languages give you but I’m not sure an incremental compiler is sufficient? These kinds of few seconds/minutes shaved add up and can impact one’s productivity.
      - tomjakubowski 3y ago
        for that kind of thing I would imagine more late binding in the language is helpful at the level Rust works, late binding is hard to do but I don't think it's impossible. Name mangling and calling conventions are a couple big obstacles.
rewmie 3y ago
> I also don't think tests should be blazing fast. I'd rather correct tests than fast tests, just like I'd rather a thorough compilation over a fast one. That's a false dilemma, and a poorly thought out strawman. The goal is not to pick between fast tests and correct tests. The goal is to pick between correct tests that are fast, and correct tests that are slow. There is absolutely zero reasons to prefer slow tests.
yawaramin 3y ago
> If you want short compile times, use interpreted languages. Or, you know, languages with fast compilers. Like Pascal, Go, OCaml. > I'd rather correct tests than fast tests I'd rather both at the same time.

by junon 3y ago

Ygg2 3y ago

I hear ya. But people are vocal about those. And thus Rust optimized those. Others (a game dev acquaintance) complains about debug performance being abysmal. At the end of the day, what people are vocal and more importantly willing to sink their time/money into will decide what happens.

izacus 3y ago

What's the biggest, oldest project you've ever worked on?

junon 3y ago
A tie between the Linux kernel and LLVM (specifically Clang). Also making game engines gets pretty hefty quite quickly. That's just open source work though. I've worked on larger systems at some Big Tech that were unwieldy, too.
- izacus 3y ago
  And at no point were you bothered by the timewaste C/C++ compiling (and especially, unavoidable linking!) brings to your work process, CI process and general ability to quickly debug and iterate on a hard problem?
  - pertymcpert 3y ago
    It depends on the problem. For some problems where you’re spending time mostly thinking, and relatively little time actually typing code, the compile times don’t really matter that much. For LLVM for example, with clangd configured to do code completion and syntax checking in the editor, you don’t really have to do as many build/test cycles. That said, I think fast compile times are important for the other use cases.

dllthomas 3y ago

I use rust because of the value it brings for the reasons you say and for others, but it would bring me even more value if it built faster. Compile times absolutely matter; how they trade off against other things will depend on the particular project.

papruapap 3y ago

Go also have fast compilation times btw (:

Ygg2 3y ago
And a GC.
mfrw 3y ago
I don't think the compile times of Go can be even compared with Rust or any major compiled language. It does compile extremely quickly; Rust on the other end lies completely opposite on that spectrum IMO. Although, both languages are "modern", both have their pros & cons. Although this may sound like a pink elephant, but I would really want something that has the guard-rails, expresiveness & performance of Rust with the simplicity & compile-time speed of Go.
- 3836293648 3y ago
  Go is not modern and has never been modern. It's an old language that just happened to be designed and implemented recently.
  - yawaramin 3y ago
    You are looking at only the language, you should also evaluate the toolchain and runtime. Go has a toolchain that most other languages (including Rust) can only dream of.
- yawaramin 3y ago
  > Although this may sound like a pink elephant, but I would really want something that has the guard-rails, expresiveness & performance of Rust with the simplicity & compile-time speed of Go. This is basically OCaml.
  - mfrw 3y ago
    Sure, thanks for the tip. I will take a look :)

chaxor 3y ago

I am a bit surprised about this as well, since my perspective on a Rust comparison to C++, one of the more noticable issues is the extra verbosity rather than compile time. You're right about switching to interpreted languages for this reason as well. Python is so incredibly simple to write, and doesn't have any compile time at all. I think a better trade off is a language that has a long compile time, is very fast and secure, but has simpler syntax. Effectively a rust based language with simpler syntax. I recognize some of these exist, but they need to be popular enough to use as well.

oreilles 3y ago

I don't understand this take. Correct and fast are absolutely not mutually exclusive, wether it apply to tests or compilation. The rust compiler is not slow because of all the checks it performs, it's slow because of the way those checks are implemented. > If you want short compile times, use interpreted languages Interpreted languages are not compiled, so this sentence doesn't make sense.

diarrhea 3y ago
> Interpreted languages are not compiled, so this sentence doesn't make sense. Usually it's a moot point, but in the context of the post it isn't. Python, Lua and JavaScript are compiled to bytecode / intermediate representations. That's compilation, but usually not mentioned, as it's so fast. However, in this context, that speed is the exact point. Use interpreted languages if compilation times (or lack thereof) are a concern! The lines are blurry though. C# and Java are also interpreted languages (compiled to intermediate representation, then executed on the language runtime aka VM; possibly JITed to native machine code), but no one calls them that.
- oreilles 3y ago
  There is a very clear difference between compilation and interpretation: in scripting languages, a statement does not depend on the following ones to be executed, meaning that the code can just be read through. Compilation is different because the binary produced need to include the whole program, therefore the whole code has to be read and analyzed before the bytecode can be produced. Compile litterally means "group together". So compilation time obviously only applies to compiled languages. Saying that the compilation time is not a concern to you and shouldn't be to anyone is also very short sighted. I'm pretty confident that you would consider it to be a problem if a "Hello world" took a week to compile. Maybe you meant "Compilation is fast enough for me", which is fine, but there is no reason why your speed expectation should be more legitimate that anyone else's.
  - naikrovek 3y ago
    took the words right out of my mouth. compilation speed matters. it matters to some more than others, obviously, but it absolutely matters, and to some it matters a great deal.

lordnacho 3y ago

I wouldn't say compile time doesn't matter, just that it's highly non-linear. The breaking points are: - You can restart the program as you're typing it. I've been looking at Elixir lately, and if I find a bug I can fix it and immediately look at a page that's got my change. - You can compile it and it will be done before you async to something else, so you aren't waiting long. Typically you also have a good idea as to whether it will compile. - You hit compile, and you know you have to find something else to do. Sometimes it will break when you're doing this other thing and the time lost is even greater. I think this used to be normal in the punch-card era.

diarrhea 3y ago

> Rust's cuts down on total development time because of the extensive checks it performs Plus, there's rust-analyzer/LSP. It works in real-time, and catches basically everything one might care about, no compiler needed. It's kind of like a static interpreter. My use cases are modest, but so far, once r-a was happy, the compiler was as well. Mileage might vary when using crate features, possibly? Inactive features are (until Rust 1.72 at least) invisible to the compiler so issues might arise only at compile-time there. > I'd rather correct tests than fast tests, just like I'd rather a thorough compilation over a fast one. The first one is a false dichotomy though. It's not like people write fast but incorrect tests whenever given a keyboard.

_ahxg 3y ago
You can enable optional features on Rust analyser. For example, to enable ssr Leptos feature on VSCode, you'd need to create a .vscode/settings file: { "rust-analyzer.cargo.features": [ "ssr" ] } Currently, though, you cannot enable the incompatible "hydrate" feature at the same time, sadly.

stephc_int13 3y ago

A lot of us realized over the years that compilation time was a productivity killer. The workflow can be adapted to slow compilation, obviously, with some discipline and a less iterative process. But the ideal "flow" for many coders is attained with zero interruptions and being able to write-compile-test in a seamless fashion. I think that the success of interpreters in many fields is related to this. Modern compilers should maybe be split in two, a fast compile/slowish code/loose tests version and a "checks+release" one. We have incredibly fast computers, instant compilation is feasible.

amenghra 3y ago
We could do day-to-day Rust/C++/any compiled language related development with an interpreter/JIT and then compile the code once a PR is ready and the code hits CI/CD or gets deployed. The "instant" runtime doesn't even need to have the exact same behavior -- it can be 99% accurate and still be very useful.
- rewmie 3y ago
  Why would anyone subject himself to that? All mainstream build systems already support incremental builds, and in some cases it's even possible to leverage compiler cache to further shave down the time it takes to rebuild a project. Breaking down a monolithic project into submodules is all it takes to shave off a big chunk of time from a build.
  - amenghra 3y ago
    Imagine being able to set a breakpoint in a function, change something and ask the debugger to “travel” back in time and pretend the code was always what it’s been changed to. It’s something some languages give you but I’m not sure an incremental compiler is sufficient? These kinds of few seconds/minutes shaved add up and can impact one’s productivity.
    - tomjakubowski 3y ago
      for that kind of thing I would imagine more late binding in the language is helpful at the level Rust works, late binding is hard to do but I don't think it's impossible. Name mangling and calling conventions are a couple big obstacles.

rewmie 3y ago

> I also don't think tests should be blazing fast. I'd rather correct tests than fast tests, just like I'd rather a thorough compilation over a fast one. That's a false dilemma, and a poorly thought out strawman. The goal is not to pick between fast tests and correct tests. The goal is to pick between correct tests that are fast, and correct tests that are slow. There is absolutely zero reasons to prefer slow tests.

yawaramin 3y ago

> If you want short compile times, use interpreted languages. Or, you know, languages with fast compilers. Like Pascal, Go, OCaml. > I'd rather correct tests than fast tests I'd rather both at the same time.