You heard about this brand new exciting programming language called Julia and have some suggestions for how it should work. Wonderful! We’re happy to have you here and help you learn the language and listen to your ideas! However, please be aware that “new” is a relative term. Yes, Julia is newer than, say, C, which was first created in 1972 and standardized in 1989. It is not, however, new in the sense that it is still being freely designed and changed in arbitrary ways. Julia development started in 2009, so it’s been developed for over a decade. It may be new to you, but it’s not new to us: there is a large community of people (hundreds of thousands) productively and happily using Julia already.
There was a big push to stabilize the language’s syntax and standard library APIs for the release of Julia 1.0 which happened in August of 2018 (two years ago when I’m writing this). This was a hell of a time. Many fine people contributed their time, energy and ideas. We debated many things (so many things). We broke some things. We fixed some things. Then we stabilized it and released it. And there was a big party! Literally: we released it at a party at JuliaCon 2018 in London.
Along with the 1.0 release came a promise: we will not break your working Julia code until Julia 2.0. Julia, like many modern software projects, follows a standard called semantic versioning. The main gist is that when we release Julia 1.1, 1.2, 1.3, etc., we can add new features but we won’t change or delete features, so your old code will keep working. That means no more changing existing syntax. No more changing what the name of a type is. No more more changing the names of functions. No more changing the names of keyword arguments. No more changing the order of positional arguments. We can add new syntax, new functions, new names, new methods, etc. but we can’t change the existing ones (at least not the ones that are exported and documented). So, you want to change all the type names to be lowercase? No can do, I’m afraid. (Well, I’m not really sad, because having uppercase types is a useful convention that conveys information to people reading code.) You want to add a new type called xyz? Ok, we could do that, but you’ll have to make a case for it. (Probably not a great name choice since it’s lowercase and all the other type names are capitalized.)
There will be a time when we start working on Julia 2.0, which will include some breaking changes, or we wouldn’t call it 2.0, we would just call it Julia 1.x for some value of x. At that point in time, we can consider breaking changes. But despite what it sounds like, this is not the time to make all the random changes that anyone might want to. Frankly, that time has passed for Julia and will never come again. There will probably be a few renamings of unfortunately named things. But that’s not what the 2.0 release is really about.
What the 2.0 release is about is thinking about big challenges and figuring out how to address them in novel ways without having to worry about how it fits into the existing language design. Once we’ve solved some really big, outstanding problems without worrying about breaking things, we’ll stop and think about how we can fit that solution into the existing language and get from A to B. If it turns out that doesn’t actually require any breaking changes, great! We won’t break anything and we could implement that particular solution in a 1.x release. But often one finds that in order to implement a really radical solution to a hard problem, at least some corner cases of the language have to change in breaking ways. That is why 2.0 will be breaking, not because we want everyone to have to change their code because something should be spelled slightly differently.
The bottom line is that the general feel of how Julia works is done. Finito. Finished. Julia code from Julia 0.1 (not 1.0) released back in 2012 looks and feels surprisingly similar to modern Julia code, aside from a few changes to keywords for declaring new types. Julia 2.0 isn’t going to fundamentally change the way people write Julia code either. If you have great greenfield ideas for how programming languages should work, we’re happy to hear them—I love reading about new, radical ideas for programming language designs—but chances are you’re going to have to create your own programming language in order to try them out. Fortunately, that’s much easier to do today than it ever has been.