Hacker News Reader

Comment by keyle | Hacker News Reader

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! :-)

View on HN

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 (1 million lines, 4 seconds)

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

I think the correctness guarantees that Rust provides are a little stronger than what Delphi provides.

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.

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.

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.

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.

Debug builds shouldn't need to be fully optimized release builds, every time something needs to be compiled on the edit-compiled-debug loop.

Depends on your domain. For video games for example, unoptimized builds are useless if they can't run at acceptable framerates.

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

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?

Is a goal of pascal (Being famous for start as a 1-pass compiler). Delphi get it from that.

It is also a goal of Go. Glacial C++ builds at Google was a prime motivator in the creation and design of Go.

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.

Sweet. Thanks for the info. That provides a lot more context.

I never wrote Delphi myself, but I always appreciated it, because it was used to develop the first IDE I used fory first programming class. Bloodshed's Dev C++. Quite an impressive IDE, so I imagine Delphi was (still is? No idea) a great platform for desktop app development.

It is, but since Borland lost their vision how to sell software and the tools division changed hands a few times, they lost most of the customers.

Nowadays most of them are enterprise customers with big maintenance contracts.

Also for shops focusing on Windows only customers, Delphi cannot compete with .NET.

That compilation speed tends to be common on the Wirth family of languages, since Algol days.

Hence why many of us, Wirth fans, enjoy but aren't that much impressed by Go compilation speed novelty.

Still it is good that they do pursue this goal, for newer generations not to assume C and C++ compilation speeds are normal and to be expected.

Also C++ compilation can improve when moving away from its #include model. When VC++ "15" gets release we will get an improved linker with DB support and experimental module support.

Delphi didn't have anywhere near the level of optimization that modern backends like LLVM have.

Still we shouldn't need a full optimized build when on the development loop.

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.

> Delphi is not much safer than C; it's not surprising it compiles quickly.

That is a funny one....

If you forego optimizations, you can compile the Linux kernel in seconds (see tcc).

Start using lots of generics and see how fast Delphi compiles.

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

AKA, REPL: Read Evaluate Print Loop.

No, a REPL is an interactive program, whereas the ECT loop belongs to the workflow of programming.

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?

Nice. I would describe the experience (and the languages) as nice. And respectful of my time.*

* Waiting patiently for my JDK9 JShell

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

OCaml offers a great REPL-experience in the form of `coretop`. It's got auto-complete that makes exploration awesome/easy. It feels very much like IPython.

OCaml installations tend to come with both a native compiler and a byte-code compiler/runtime, so you really get the best of both worlds there - minus some occasional hiccups in the build process.

OCaml was one of the languages I had in mind when I made the remark. :)

A REPL is just an ECT loop speed up enough to be actually good.

Can we have the best of both worlds?

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.

The biggest win for that is going to be incremental compilation. I can't wait for that to stabilize.

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

Switch to TypeScript or Flow. Then at least it's worth the wait (in terms of correctness).

Can't switch in that project, but I will try TypeScript in the next

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/

If you're not, can you use Babel to use Buble?

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.

How does that clobber the global object? Are you talking about `function clearInterval()`? That doesn't go into the global scope.

    > let foo = function bar() {}
    undefined
    > bar
    ReferenceError: bar is not defined

It doesn't overwrite the function on the global scope, but it does shadow the `clearInterval` name within the function definition, which I don't believe it should do according to the ES6 spec. Compare:

https://buble.surge.sh/#class%20A%20%7B%0A%20%20clearInterva...

with

https://babeljs.io/repl/#?babili=false&evaluate=true&lineWra...

If you're targeting modern browsers you may want to look into disabling all plugins except for modules. The latest version of every major browser supports ES2015 natively (as well as much of ES2016 and ES2017). There are various Babel presets (eg. babel-preset-modern) available on NPM that do this.

Even if you're not targeting modern browsers, you might consider developing on Chrome with a very minimal, modules-only Babel config, and then running the full transform only when you're ready to QA & deploy.

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.

Reply on news.ycombinator.com