Draft blog post

1 files changed, 61 insertions, 0 deletions

diff --git a/docs/2015-10-23-dotty-compiler-bootstraps.md b/docs/2015-10-23-dotty-compiler-bootstraps.md
new file mode 100644
index 000000000..bd285a035
--- /dev/null
+++ b/docs/2015-10-23-dotty-compiler-bootstraps.md
@@ -0,0 +1,61 @@
+---
+layout: blog
+post-type: blog
+by: Martin Odersky and Dmitry Petrashko
+title: We Got LiftOff! The Dotty Compiler for Scala Bootstraps.
+---
+
+
+The Dotty project is a platform to develop new technology for Scala
+tooling and to try out concepts of future Scala language versions.
+Its compiler is a completely new design intended to reflect the
+lessons we learned from work with the Scala compiler. A clean redesign
+today will let us iterate faster with new ideas in the future.
+
+Today we reached an important milestone: The Dotty compiler can
+compile itself, and the compiled compiler can act as a drop-in for the
+original one. This is what one calls a "bootstrap".
+
+## Why is this important?
+
+The main reason is that this gives us a some validation of the
+trustworthiness of the compiler itself. Compilers are complex beasts,
+and many things can go wrong. By far the worst things that can go
+wrong are bugs where the compiler produces incorrect code for a
+correct program. It's not fun debugging code that looks perfectly
+fine, yet gets translated to something subtly wrong by the compiler.
+
+Having the compile compile itself is a good test to demonstrate that
+the generated code has reached a certain level of quality. Not only is
+a compiler a large program (44k lines in the case of dotty), it is
+also one that exercises a large part of the language in quite
+intricate ways. Moreover, bugs in the code of a compiler don't tend to
+go unnoticed, precisely because every part of a compiler feeds into
+other parts and all together are necessary to produce a correct
+translation.
+
+## Are We Done Yet?
+
+Far from it! The compiler is still very rough. A lot more work is
+needed to
+
+ - make it more robust, in particular when analyzing incorrect programs,
+ - improve the efficiency of generated code,
+ - improve error messages and warnings,
+ - embed it in external tools such as sbt, REPL, IDEs,
+ - remove restrictions on what Scala code can be compiled,
+ - help in migrating Scala code that will have to be changed.
+
+## What Are the Next Steps?
+
+Over the coming weeks and months, we plan to work on the following topics:
+
+ - Make snapshot releases
+ - Get the Scala standard library to compile,
+ - Work on SBT integration of the compiler
+ - Work on IDE support
+ - Investigate best way we can implement a REPL,
+ - Work on the build-infrastructure.
+
+If you want to get your hands dirty with any of this, now is a good moment to get involved!
+