5 ms·

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 sa

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.

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.