If it isn’t obvious, this is an April Fool’s joke.
However, lily is actually written in C.
So the joke is that it was never written in Rust in the first place?
The fact that it was a joke is very much not obvious.
Like any good April fools joke, it should make you question why you didn’t know it was a joke.
It is a joke, however I think there are a few valid point. On the other side check this: https://github.com/FascinatedBox/lily/issues/294
I don’t know what the author’s intention was.
It could be an actual commentary on Rust, under the guise of an April fool’s joke. Equally likely, it could be an attempt at satire.
Would have to ask the author to be sure.
One real takeaway that I didn’t know about is D having a super-fast compiler despite being a C++ alternative with plenty of features. That would be quite a benefit of combining advanced, C/C++-like language with fast iterations. Unless those are April Fools jokes themselves with actual compiler slow as Christmas. Anyone got something on compilation speed of D written on another day? (sighs)
I can’t source this but I have very, very, very vague memories of Walter Bright having said something about D just being designed so that the compiler never needs to iterate over all bytes in the source file more than once. Some sort of module system instead of textual #include, (I think no textual macro expansion), well-designed lexical syntax to keep the lexer simple and well-designed grammar to keep the parser simple.
I got the impression from looking at D very briefly that many of D’s features are things that can fairly straightforwardly be flattened out on the way to turning it into IR? Things like scope guards, goto case, with statements.
Here’s an interview in which W Bright talks about implementing a C preprocessor that he+FB claim makes their builds noticeably faster on real-world C++ software: https://code.facebook.com/posts/476987592402291/under-the-hood-warp-a-fast-c-and-c-preprocessor/ — note that he mentions that his newly written cpp replacement touches every byte of input five times. I think his words imply that existing slower cpp implementations touch every byte more times than that.
One of Walter’s rules is “must not require data flow analysis”. He is quite obsessed with compilation speed, in a good way. I agree with him. Everything which shortens the change-build-debug cycles improves programmer productivity. A powerful type checker like in Rust does too. It is hard to say, what is more important. I would like to have both. ;)
Roughly, D compiles as fast as Go. Two caveats:
If performance is paramount, you should use the LLVM backend (ldc), which is slower to compile, but gives you another ~10% speed for the generated code. You could use dmd for development and ldc for the release build.
D has Turing-complete meta programming, so compilation can be arbitrarily slow depending on the code. The compile time interpreter is also not as fast as it could be, thus the current work to make it faster.
Edit: From 2010: Go compiles “120KLOC in 9.23 seconds” vs D “88KLOC in 1.24 seconds”.
Also, Walter on making D compiler faster.
Rust also reads the source files exactly once. It has a module system and no textual macro thing.
Rustc is slow due to other reasons – the compilation units are large, for one, so every change is like editing a header file. This may change soon with incremental compilation.
The D compiler is fast. As far as I can tell, a big part of the advantage over C++ is because the metaprogramming language (a compile-time subset of D) actually has loops and operators, instead of relying on a brain dead accidental language like C++.
Appreciate the confirmation. I also expected the evolution of C++ to have a negative effect vs languages designing it in from the beginning.
We like to pretend compile time isn’t a big deal, but it really is. I’ve been using C++, Go and Myrddin for the past year or so and this alone hurts C++ so bad by comparison to Myrddin/Go’s fast build times.
tinyc is pretty amazing