8 ms·

I've never used rust but seeing it's so oriented towards correctness and type checking, I'm not surprised it's a little slow to compile! From someone stuck wit

by keyle 10y ago

I've never used rust but seeing it's so oriented towards correctness and type checking, I'm not surprised it's a little slow to compile! From someone stuck with dynamic languages, mark my words, it's best for your compiler to be a bit slow, than your brain being the compiler! :-)

vintagedave 10y ago
Why? You can have both fast compilers and safe languages. Take Delphi for example: statically typed, strong type correctness, you have to work to avoid type safety. Compiles a million lines of code in 4 seconds (including linking.) * https://www.youtube.com/watch?v=Yq2mNUzcpE0 https://www.youtube.com/watch?v=Yq2mNUzcpE0 (1 million lines, 4 seconds) * https://www.youtube.com/watch?v=kvuxeaMDmMc https://www.youtube.com/watch?v=kvuxeaMDmMc (277,000 lines of much more complex code (the most complex, compiler-stressing library Delphi has) in 16 seconds counting linking.
- adrianN 10y ago
  I think the correctness guarantees that Rust provides are a little stronger than what Delphi provides.
  - bryanlarsen 10y ago
    Perhaps more significantly, the checking that Delphi provides is both explicit and local. Rust does a lot more inferential checks and at the crate level rather than at the line level.
    - Rusky 10y ago
      Rust's inference and checks are actively limited to function level, not crate level- function types are not inferred, generics are type-checked before instantiation, the borrow checker works on individual functions, etc.
- krylon 10y ago
  At work, I am stuck doin maintenance on an in-house application our accounting department uses, which is written in Delphi. It's small (~10k lines of code), but it compiles so fast I sometimes wonder if I clicked the wrong button / hit the wrong key.
- userbinator 10y ago
  I don't know about the latest versions, but I remember looking at Delphi compiler output and it seemed like it did not optimise at all. That would certainly explain its speed.
  - pjmlp 10y ago
    Debug builds shouldn't need to be fully optimized release builds, every time something needs to be compiled on the edit-compiled-debug loop.
    - Narishma 10y ago
      Depends on your domain. For video games for example, unoptimized builds are useless if they can't run at acceptable framerates.
      - pjmlp 10y ago
        I am aware of that, but it should be up to the developers to choose. And I am not making this up, it is how Eiffel, Lisp, JVM, .NET and Swift (from what I could gather in WWDC presentations) toolchains work. Also how long gone C++ toolchains like Lucid C++ and IBM Visual Age for C++ (only the v4.0) used to work. Even Microsoft is going this route for C++ on the upcoming VS "15", with the help of new linker and the experimental modules support. https://blogs.msdn.microsoft.com/vcblog/2016/10/05/faster-c-build-cycle-in-vs-15-with-debugfastlink/ https://blogs.msdn.microsoft.com/vcblog/2016/10/05/faster-c-...
- chamakits 10y ago
  I'm not familiar enough to comment on what different feature set and different type of work each compiler does to compare the speed, but WOW, that's an INSANE quick build speed. Was it always an explicit goal of theirs compilation speed? Is there any documentation of specific things they did to achieve that build speed?
  - mamcx 10y ago
    Is a goal of pascal (Being famous for start as a 1-pass compiler). Delphi get it from that.
    - topspin 10y ago
      It is also a goal of Go. Glacial C++ builds at Google was a prime motivator in the creation and design of Go.
  - mike_hearn 10y ago
    I used to use Delphi a lot, in the 1990's. It's a few things. Compiler designed for compilation speed above all else. Delphi did not attempt to ever compete with other languages/toolchains on raw runtime performance of the generated code .... I don't recall ever seeing Borland/Inprise boast that a new version generated more optimal code. This is because the code the compiler produced was fast enough for Delphi's target market (desktop business apps) and it was still a lot faster than Visual Basic, and a lot more compact than Java, which were its primary competitors. Delphi sold new versions to developers by giving them new productivity tools: for desktop apps that spend all their time idling, raw code performance was rarely an issue. Single pass compiler. Structuring Delphi apps could be a nightmare. You could not have circular unit dependencies and breaking such dependencies could often be irritating as hell. Functions had to be declared in the right order. No preprocessor or include based model. "Units" defined their header and implementation in the same file, so the compiler could rapidly load a binary representation of what a unit exported whilst it was compiling. No generics. Thus, no explosion of code to generate at runtime, like with C++. Grammar that was very easy to parse. Compiler codebase that at its core was designed for very old computers, so is/was very tightly written. Probably more. That's just what I recall.
- pcwalton 10y ago
  Delphi didn't have anywhere near the level of optimization that modern backends like LLVM have.
  - pjmlp 10y ago
    Still we shouldn't need a full optimized build when on the development loop.
- duaneb 10y ago
  Delphi is not much safer than C; it's not surprising it compiles quickly. It's also not competitive speed-wise with either clang/gcc OR rust.
  - pjmlp 10y ago
    > Delphi is not much safer than C; it's not surprising it compiles quickly. That is a funny one....
- whyever 10y ago
  If you forego optimizations, you can compile the Linux kernel in seconds (see tcc).
- mmargerum 10y ago
  Start using lots of generics and see how fast Delphi compiles.
ekr 10y ago
Never underestimate the edit-compile-test loop. It has an huge impact on productivity.
- aninhumer 10y ago
  Well with stronger type guarantees, a lot of the "test" part of that loop gets pushed into "compile". Indeed the core loop becomes edit-typecheck, and while the compiler can be slow, the type checker tends to be a lot faster than the test suite.
- arunc 10y ago
  AKA, REPL: Read Evaluate Print Loop.
  - majewsky 10y ago
    No, a REPL is an interactive program, whereas the ECT loop belongs to the workflow of programming.
    - pjmlp 10y ago
      So how would you describe the experience of languages that offer both a REPL and also have integrated toolchains for AOT compilation to native code?
      - sgift 10y ago
        Nice. I would describe the experience (and the languages) as nice. And respectful of my time.* * Waiting patiently for my JDK9 JShell
        krylon 10y ago
        There used to be a program called BeanShell that tried to provide a REPL for Java, but it was not as nice as the REPLs offered by, e.g. Python or Ruby (Let alone Lisps where the debugger is integrated into the REPL). OTOH, I looked at it years ago, so maybe it has gotten better (or it stagnated completely).
pjmlp 10y ago
Still it can be improved and it is nice to see work being done there. For me, the sweet spot would be the compilation speed of Delphi, .NET Native and similar languages.
k__ 10y ago
> From someone stuck with dynamic languages, mark my words, it's best for your compiler to be a bit slow, than your brain being the compiler! lol, I'm on a project right now that uses ES2016 (dynamic) and I'm still stuck on a slow compiler.
- patates 10y ago
  Switch to TypeScript or Flow. Then at least it's worth the wait (in terms of correctness).
  - k__ 10y ago
    Can't switch in that project, but I will try TypeScript in the next
- jnbiche 10y ago
  If you're only using standard ES6 features, you may be able to switch to Buble. I got a pretty significant speedup after switching one project to Buble ES6 compiler. https://buble.surge.sh/guide/ https://buble.surge.sh/guide/
  - hueving 10y ago
    If you're not, can you use Babel to use Buble?
  - moron4hire 10y ago
    Buble is subtly broken in a number of ways. For example, if any of your method names mirror something you need in the global namespace, your method will clobber that global object. For example: class A { constructor() { this.handle = setInterval(/* blah */, 1000); } clearInterval() { clearInterval(this.handle); } } Becomes: function A() { this.handle = setInterval(/* blah */, 1000); } A.prototype.clearInterval = function clearInterval() { clearInterval(this.handle); }; And if you're switching from babel to buble, you'll be confused as to why you're suddenly getting a bunch of stack overflow errors. I have a fairly large project and don't see a significant difference in compile times between the two. Slowness in my build process usually means I've accidentally touched the node_modules directory in my gulp.src expression. It's not enough to use a negation! You have to avoid testing it completely.

by keyle 10y ago

vintagedave 10y ago

Why? You can have both fast compilers and safe languages. Take Delphi for example: statically typed, strong type correctness, you have to work to avoid type safety. Compiles a million lines of code in 4 seconds (including linking.) * https://www.youtube.com/watch?v=Yq2mNUzcpE0 https://www.youtube.com/watch?v=Yq2mNUzcpE0 (1 million lines, 4 seconds) * https://www.youtube.com/watch?v=kvuxeaMDmMc https://www.youtube.com/watch?v=kvuxeaMDmMc (277,000 lines of much more complex code (the most complex, compiler-stressing library Delphi has) in 16 seconds counting linking.

adrianN 10y ago
I think the correctness guarantees that Rust provides are a little stronger than what Delphi provides.
- bryanlarsen 10y ago
  Perhaps more significantly, the checking that Delphi provides is both explicit and local. Rust does a lot more inferential checks and at the crate level rather than at the line level.
  - Rusky 10y ago
    Rust's inference and checks are actively limited to function level, not crate level- function types are not inferred, generics are type-checked before instantiation, the borrow checker works on individual functions, etc.
krylon 10y ago
At work, I am stuck doin maintenance on an in-house application our accounting department uses, which is written in Delphi. It's small (~10k lines of code), but it compiles so fast I sometimes wonder if I clicked the wrong button / hit the wrong key.
userbinator 10y ago
I don't know about the latest versions, but I remember looking at Delphi compiler output and it seemed like it did not optimise at all. That would certainly explain its speed.
- pjmlp 10y ago
  Debug builds shouldn't need to be fully optimized release builds, every time something needs to be compiled on the edit-compiled-debug loop.
  - Narishma 10y ago
    Depends on your domain. For video games for example, unoptimized builds are useless if they can't run at acceptable framerates.
    - pjmlp 10y ago
      I am aware of that, but it should be up to the developers to choose. And I am not making this up, it is how Eiffel, Lisp, JVM, .NET and Swift (from what I could gather in WWDC presentations) toolchains work. Also how long gone C++ toolchains like Lucid C++ and IBM Visual Age for C++ (only the v4.0) used to work. Even Microsoft is going this route for C++ on the upcoming VS "15", with the help of new linker and the experimental modules support. https://blogs.msdn.microsoft.com/vcblog/2016/10/05/faster-c-build-cycle-in-vs-15-with-debugfastlink/ https://blogs.msdn.microsoft.com/vcblog/2016/10/05/faster-c-...
chamakits 10y ago
I'm not familiar enough to comment on what different feature set and different type of work each compiler does to compare the speed, but WOW, that's an INSANE quick build speed. Was it always an explicit goal of theirs compilation speed? Is there any documentation of specific things they did to achieve that build speed?
- mamcx 10y ago
  Is a goal of pascal (Being famous for start as a 1-pass compiler). Delphi get it from that.
  - topspin 10y ago
    It is also a goal of Go. Glacial C++ builds at Google was a prime motivator in the creation and design of Go.
- mike_hearn 10y ago
  I used to use Delphi a lot, in the 1990's. It's a few things. Compiler designed for compilation speed above all else. Delphi did not attempt to ever compete with other languages/toolchains on raw runtime performance of the generated code .... I don't recall ever seeing Borland/Inprise boast that a new version generated more optimal code. This is because the code the compiler produced was fast enough for Delphi's target market (desktop business apps) and it was still a lot faster than Visual Basic, and a lot more compact than Java, which were its primary competitors. Delphi sold new versions to developers by giving them new productivity tools: for desktop apps that spend all their time idling, raw code performance was rarely an issue. Single pass compiler. Structuring Delphi apps could be a nightmare. You could not have circular unit dependencies and breaking such dependencies could often be irritating as hell. Functions had to be declared in the right order. No preprocessor or include based model. "Units" defined their header and implementation in the same file, so the compiler could rapidly load a binary representation of what a unit exported whilst it was compiling. No generics. Thus, no explosion of code to generate at runtime, like with C++. Grammar that was very easy to parse. Compiler codebase that at its core was designed for very old computers, so is/was very tightly written. Probably more. That's just what I recall.
pcwalton 10y ago
Delphi didn't have anywhere near the level of optimization that modern backends like LLVM have.
- pjmlp 10y ago
  Still we shouldn't need a full optimized build when on the development loop.
duaneb 10y ago
Delphi is not much safer than C; it's not surprising it compiles quickly. It's also not competitive speed-wise with either clang/gcc OR rust.
- pjmlp 10y ago
  > Delphi is not much safer than C; it's not surprising it compiles quickly. That is a funny one....
whyever 10y ago
If you forego optimizations, you can compile the Linux kernel in seconds (see tcc).
mmargerum 10y ago
Start using lots of generics and see how fast Delphi compiles.

ekr 10y ago

Never underestimate the edit-compile-test loop. It has an huge impact on productivity.

aninhumer 10y ago
Well with stronger type guarantees, a lot of the "test" part of that loop gets pushed into "compile". Indeed the core loop becomes edit-typecheck, and while the compiler can be slow, the type checker tends to be a lot faster than the test suite.
arunc 10y ago
AKA, REPL: Read Evaluate Print Loop.
- majewsky 10y ago
  No, a REPL is an interactive program, whereas the ECT loop belongs to the workflow of programming.
  - pjmlp 10y ago
    So how would you describe the experience of languages that offer both a REPL and also have integrated toolchains for AOT compilation to native code?
    - sgift 10y ago
      Nice. I would describe the experience (and the languages) as nice. And respectful of my time.* * Waiting patiently for my JDK9 JShell
      - krylon 10y ago
        There used to be a program called BeanShell that tried to provide a REPL for Java, but it was not as nice as the REPLs offered by, e.g. Python or Ruby (Let alone Lisps where the debugger is integrated into the REPL). OTOH, I looked at it years ago, so maybe it has gotten better (or it stagnated completely).

pjmlp 10y ago

Still it can be improved and it is nice to see work being done there. For me, the sweet spot would be the compilation speed of Delphi, .NET Native and similar languages.

k__ 10y ago

> From someone stuck with dynamic languages, mark my words, it's best for your compiler to be a bit slow, than your brain being the compiler! lol, I'm on a project right now that uses ES2016 (dynamic) and I'm still stuck on a slow compiler.

patates 10y ago
Switch to TypeScript or Flow. Then at least it's worth the wait (in terms of correctness).
- k__ 10y ago
  Can't switch in that project, but I will try TypeScript in the next
jnbiche 10y ago
If you're only using standard ES6 features, you may be able to switch to Buble. I got a pretty significant speedup after switching one project to Buble ES6 compiler. https://buble.surge.sh/guide/ https://buble.surge.sh/guide/
- hueving 10y ago
  If you're not, can you use Babel to use Buble?
- moron4hire 10y ago
  Buble is subtly broken in a number of ways. For example, if any of your method names mirror something you need in the global namespace, your method will clobber that global object. For example: class A { constructor() { this.handle = setInterval(/* blah */, 1000); } clearInterval() { clearInterval(this.handle); } } Becomes: function A() { this.handle = setInterval(/* blah */, 1000); } A.prototype.clearInterval = function clearInterval() { clearInterval(this.handle); }; And if you're switching from babel to buble, you'll be confused as to why you're suddenly getting a bunch of stack overflow errors. I have a fairly large project and don't see a significant difference in compile times between the two. Slowness in my build process usually means I've accidentally touched the node_modules directory in my gulp.src expression. It's not enough to use a negation! You have to avoid testing it completely.