Hacker News Reader

Comment by rictic | Hacker News Reader

What would a compiler for a language like Rust or C++ look like if it was optimized for development iteration speed first? Could you produce binaries that were good enough to be useful for testing and developing?

You'd end up sharing a lot of the same infrastructure that you'd want for an LSP server, basically to do as much preprocessing as you could on the initial compilation and then work incrementally on top of that.

You'd also of course still want your globally-optimizing batch mode compiler for production, but for many projects it seems like such a thing could produce good enough binaries for development, and greatly improve engineer productivity.

View on HN

A good example is what IBM did with Java back in the day (already in 1997). They built an incremental Java compiler (jikes) that was intended for use during development. This later became the basis for the eclipse compiler which is the compiler Eclipse uses to ensure all Java code is compiled and ready to run the millisecond you stop typing. It's also able to compile and run broken code and it simply will error if you hit the broken parts. Things like autocomplete and other IDE features work even if your code is clearly broken and it will tell you it is broken. Being able to iterate on editing and running unit tests without any noticeable delay is very nice.

Here's a good overview of this on Stackoverflow: https://stackoverflow.com/questions/3061654/what-is-the-diff...

For Rust, it looks like they are following a similar approach with the rust analyzer. This is indeed not intended for building production code, which you'd typically do on some CI server and using optimizations that maybe make the process a bit slower but the output a bit faster/smaller.

Microsoft's Roslyn [1] design (now called .NET Compiler Platform) is what I think any language should strive for, turning the classical black box of the compiler into an incremental pipeline where each stage is annotated/augmented/refined by different mechanisms such as type checkers.

If each step is incremental, it follows that it's easier to also let each step "integrate" deltas; for example, adding a comment shouldn't need to recompile anything at all, merely modify the AST, because it doesn't lead to any actual code artifacts. The second benefit is that all the information needed to inspect the program — from syntax highlighting to type information — is already there.

If you can keep the entire high-level compilation state in memory, then it's easy to query it for all sorts of IDE features. This same design was used for the TypeScript compiler. Anders Heljsberg has a great little lecture [2] about it.

[1] https://github.com/dotnet/roslyn/wiki/Roslyn-Overview

[2] https://www.youtube.com/watch?v=wSdV1M7n4gQ

I"m not too familiar with either Roslyn or the Eclipse Java Compiler (ecj), but since ecj was developed specifically for deep integration into Eclipse JDK, I'd assume that it ended up being really similar (and it would have preceded Roslyn by a couple of years).

I don't know the internal architecture of the Eclipse compiler, but one of the points of the Roslyn architecture is to turn the compiler into an API, allowing things like inserting plugins — custom linter rules, for example — at each point in the pipeline.

Eclipse is interesting in that it grew out of IBM's VisualAge for Java, which was written in Smalltalk as an extension of the original VisualAge IDE/compiler, which goes back all the way to the mid-1980s. I wonder if any of the inspiration for this design came out of Smalltalk's runtime state being persistent. If all your state is derived from earlier state, then there's no need to always start processing from scratch, since you can just continue from where you were before.

That Anders Heljsberg video is great. Watched it last night and I'm still thinking through the implications of pull vs push. Thanks!

It'd look like Delphi i'd guess, at least the earlier versions. Delphi 2 is stupidly fast, almost instant compilation on a contemporary PC that runs at around 200MHz with 16MB of RAM and practically instant (in that it is impossible to notice it) in any modern PC (a synthetic benchmark i wrote some weeks ago had it compile a bit above 10MLOC in 5.56 seconds on my 3700X CPU, which is an average priced consumer CPU - on a single thread).

While it doesn't have the niceties added in later versions and in Free Pascal (like dynamic arrays, generics, anonymous functions and a few other things) it still has more than enough features to create big complex applications (e.g. object oriented language, rich RTTI that allows automatic serialization, properties, native string support, optional reference counting, real module support).

In terms of generated code... well, it isn't exactly great (it came last on this benchmark i wrote some time ago http://runtimeterror.com/tools/raybench/ that compares some C and Pascal compilers - i mainly wrote it for retrocoding, but threw in some modern compilers as well - EDIT: i misremembered, it didn't came last, Borland C++ 5.0 came last, in fact it came slightly above Free Pascal 3.0.4 with its default settings, though by enabling 64bit and modern instructions FPC was able to generate much faster code).

But then again, it is written in itself and as i wrote, it is stupidly fast. So it does the work perfectly fine for most tasks - as long as you don't need brute force number crunching.

Of course i'm not advocating the use of Delphi 2 (and i do not know how it compares with modern Delphi - last time i tried out the free version they have the entire IDE felt very weird and sluggish). However the fact that it exists is a proof that you can have a very fast compiler and IDE for a rich language that produces very good code - maybe not the best possible code, but good enough for a large majority of tasks.

So C++ Builder. :)

Modern Delphi is still quite fast.

C++ Builder 1 (which is contemporary to Delphi 2) is much slower than Delphi 2. It just happens to be faster than any other (full featured - i mean including IDE, debugger and such) C/C++ compiler of its time, but doesn't hold a candle to Delphi 2. Even the IDE is much more sluggish (in 90s hardware, in anything released this side of the millennium it doesn't make much difference :-P).

I don't know about the latest version of modern Delphi, but as i wrote, when i tried the free version 2-3 years ago it wasn't that fast. Lazarus felt faster and much snappier. Perhaps the non-LLVM Delphi compiler (if it is still available) is faster (the Delphi 2 compiler is certainly faster than FPC) but it is held down by all the bloat piled on top.

My point is that still run circles around several AOT compiled languages, including the C++ compilers FOSS devs tend to use, let alone languages like Rust and Swift (on their current state).

I would be quite happy with the compile speed of the latest Delphi version when using Rust.

Ah yeah, but i do not think C++ or Rust are any sort of compilation speed benchmarks (though the C++ compiler used in BCB1 is very fast... for C++) :-P. Free Pascal (which is still much slower than Delphi 2 in terms of compilation speed), D, Go and i'm sure several other AOT languagesi'm forgetting right now have fast compilers.

BTW i haven't used Delphi since its use of LLVM (or it wasn't in the free version) but didn't it affect the compiler's speed?

I was curious about the current state of Delphi, so I downloaded its latest community edition last week, and it still looks quite fast to me.

I started out with Pascal. Compilation was such a non-event... Subjectively entire programs compiled faster than a line of Julia takes today. Then again, if I remember correctly Pascal the language was written with ease of compiling in mind. My compiler today has to do a lot more work so I can do a lot less...

Yeah although Delphi/Object Pascal - even in its Delphi 2 incarnation - is a much more complicated beast than Wirth's Pascal. But i think most of the extensions that were introduced over the years were still in the same spirit of easy compilation and parsing.

The Delphi compiler is probably structured similarly to the Rust compiler. They're both classical compiler designs. Rust takes longer to compile for other reasons.

It's in the works :)

https://www.reddit.com/r/rust/comments/enxgwh/cranelift_back...

https://github.com/bytecodealliance/cranelift

It would look like Lucid Energize for C++, here a 1993 sales demo:

https://www.youtube.com/watch?v=pQQTScuApWk

Or the version 4 of IBM's Visual Age for C++

Visual Age for C++ was quite impressive, the whole program was serialized into a database, an approach similar to Energize, and you could edit C++ code just like in a Smalltalk environment.

Sadly not much of it has survived, so save pages like this while they exist

http://www.edm2.com/index.php/VisualAge_C%2B%2B_4.0_Review

The problem with those two products was that they were ahead of their time, so with their hardware requirements, ended up being a commercial failure.

Then for something more down to earth, there is C++ Builder, the only actual C++ RAD tooling, but their market is only deep pocket corporations. Think VB experience, but using C++ instead.

https://www.embarcadero.com/products/cbuilder/

Finally there is VC++, which also supports edit-and-continue with incremental compilation and linking, and with C++/CX I thought it could eventually be like C++ Builder but was wrong. Also with the C++/WinRT reboot, the tooling is still playing catch up with C++/CX.

However there is also the option to use interpreters like Cling.

Then you also have the development experience of Common Lisp, Dylan and Eiffel.

All of those have rich IDEs, with interpreter/JIT compilers for development, and then you can also AOT optimize for release builds.

Eiffel to this day uses their JIT (oder MELT as they call it) for rapid development, and then relies on a C or C++ compiler for the release builds.

Dylan while killed by Apple, had a short commercial life, and you can still get old of its open source variant, althought the IDE is Windows only.

https://opendylan.org/index.html

Common Lisp experience is available on LispWorks and Allegro CL.

The Mun language is going down the “iteration speed as #1 priority” path. It’s written in Rust and made to also be compatible with C/C++

https://mun-lang.org/

> optimized for development iteration speed first

I know! we need differentiable compilers! :)

I'm surprised that you consider compilation to be a big productivity limitation (at least where current rust or C++ compilers at low optimization levels aren't enough). A faster computer with more cores addresses compilation speed, but also makes tests run fast. :)

Supermicro sells boxes with up to 4 dual socket zen2 boards (512 cores!) that fit in 2U, e.g. 2124BT-HNTR ... :P and you can stick a bunch of developers remotely connected concurrently compiling on it.

That's pretty much what rust-analyzer aims to be.

Probably go or d.

Slightly tangential but one thing I absolutely love about sbt/play framework is the frigging development loop. You start play using `play ~run`, save changes and by the time you've switched to your browser, the source has been compiled to `.class` and you are ready to hit f5.

It's almost magical, DESPITE scala being slow as snail at compilation.

The scala metals LSP server also has better than enterprise grade documentation. https://scalameta.org/metals/docs/editors/vim.html

The Bloop project is doing amazing work as well in making Scala compilation leagues faster (even faster than SBT). I hear Scala 3 should help significantly in this area as well.

I wish this would be a higher priority generally, developer time being as expensive as it is.

Reply on news.ycombinator.com