That’s the main problem.
- Windows support won’t be possible without breaking changes (because stdlib is still uses some posix concepts).
- Multithreading could require breaking changes in stdlib. I’m not sure how big they could be.
- Incremental compilation won’t (or very unlikely to) be possible without breaking changes, and those changes could be BIG, similar to what happened in https://github.com/crystal-lang/crystal/issues/1824.
- Current implementation of generics is “well, they works”. They are powerful enough to use them in simple cases (and even for an stdlib with all those Iterator\Iterables), but once you try to do something more advanced you will see rough edges. It is possible to construct cases that won’t work by design, and any fixes would possibly require breaking changes. Answering “do not use generics inheritance for now, it is broken” to issues in 1.0 language isn’t fine, generics inheritance should be limited to cases that are not broken by defined semantics, not compiler implementation.
- Macros are similar thing. They are powerful but “hacky”, many things there look like a temporary solution.
- Aaand there still exhaustive case, removal\fix of private types, simplification of Int\Float, and plenty of similar things that are breaking changes too and should be decided before 1.0.
Personally I believe that (1), (2), and (6) could be done in one year, so 1.0 in 2020 would mean lack of modular compilation, strange generics and macroses for all 1.x versions.
I think my tone could be slightly too critical. I don’t want to say crystal is bad - it is wonderful, much better than any alternatives and i love it with all it’s limitations.
But 1.0 mean that it’s development in mentioned fields (and possible some other) will be stopped or severely limited, and that would be sad.