This seems like a good idea. Rust is doing something they call the Libz Blitz, which sounds like a formalized version of what you suggest, except they are doing it at their version 1.17.
8 Likes
That is a great link! I think that the Julia package ecosystem could really benefit from some similarly focused attention. Unfortunately, I’m worried that the folks at Julia Computing feel so much pressure to release 1.0 that they aren’t going to be willing to take this sort of extended pause. Hopefully I’m wrong…
6 Likes
Type annotations for value type parameters.
This may be something that’s already possible and I’ve just not found it, but it bothers me that I can write Array{Int, 1} and Array{1, Int} and not get an error (admittedly, it errors when you try and call a constructor) . Similarly when I’m creating types I’d like to be able to constrain parameters to be either a DataType or a specific isbits type if it’s a value type. I think it would be helpful from a bug reduction/self documenting code point of view.
(Hopefully I’ve used the correct terminology here and this makes sense)
1 Like
This is a great thread, thank you all. If I squint I can see pretty good consensus around what the biggest issues are, and the list doesn’t seem too horribly long.
As for the timing of 1.0, we have to strike a balance. With a later (and hopefully better) release, julia would be easier to adopt, but we would run lower on resources and possibly miss opportunities in the meantime. In particular, we can’t schedule 1.0 to land on the day we run out of money, so we have much less time to work on it than one might think.
I see the point about tension between semantic versioning (which demands stability) and public perception (which demands cool features). If we’re strict about prioritizing breaking changes, perhaps we can release a 1.0-beta fairly early, giving ourselves more time to work on the debugger and packages before 1.0-final.
25 Likes
Wow that rust initiative is my dream. Everything so so nicely laid out. Will be interesting to see if they can pull this off.
1 Like
There is a work in progress Logging Julep:
https://github.com/JuliaLang/Juleps/pull/30
Please contribute with feedback and use cases.
2 Likes
I would add to what Jeff said that there’s a significant bottleneck that prevents releasing all of the things in perfect shape at the same time: a lot of the same people do the critical work on Julia itself as well as the packages that people are miffed about the up-to-dateness of. If we had human cloning technology, we would have used it on Keno by now 
. Ditto for Jeff, Jameson and many other spectacular folks who already do more than seems possible for a single person. To improve this situation, the best approach is to increase the number of people who can work on Julia and important packages. If you’re not an industrial foundation that can directly fund development like the Sloan and Moore foundations, then the best thing you can do to reduce the bottleneck is likely to become one of those people yourself.
Since we cannot implement all of the things at once, the strategy that we’re taking is to stabilize the core language first, then turn our attentions to important packages, tooling, and compiler improvements that we can make without breaking things for people. Since the core language will be stable, we will have a solid foundation to build on. If we had unlimited resources, sure, we would release Julia 1.0 and all of the packages and tooling one could possibly want in perfect shape. But our resources are far from unlimited, so we’re taking the same strategy that Rust, Go, Clojure, Swift, and every other new programming language I can think of has taken: stabilize the core language, then once that’s done, turn your attention to important libraries and tools. That’s exactly what the Rust “Libz Blitz” linked to here is about. Rust is just a couple of years ahead of us: they released their 1.0 version a couple years ago; since then, they’ve spent a few years working on tooling; now they’re turning their attention to the package and library ecosystem.
18 Likes
My wishlist for 1.0 only has one item:
- Faster interactive use in the REPL. Python is a slow language that feels fast in the REPL, Julia is a fast language that feels slow in the REPL. Package load times and function compilation times mean that a simple command line program.jl takes 11 seconds until it displays a DocOpt.jl help message (in 0.6.0 on a 64 core machine). To me this is the single most important pain point in everyday Julia use. I am sure there are substantial technical challenges but in many cases during development I would happily give up JIT-compiled performance and settle with a simple and slow interpreter if this would mean that I can run things as interactive as in Python.
6 Likes
I don’t disagree that faster load and compile times are extremely important, but they are exactly the kind of thing that is not crucial for 1.0 – optimizations and compile time improvements can be done any time. The 1.0 release is about stabilizing APIs and the standard library. The 1.1 release can make as many performance improvements as we can manage – no one will complain about their code doing the same thing only faster. The promise of 1.0 is that you can write code knowing that it will continue to work and that the language will only get faster and better while your code continues to work.
18 Likes
As stated above, I like this idea a lot since maintaining large amounts of code through breaking releases is cumbersome. However, how do you plan on managing expectations with the 1.0 release? I think it’s fair to say that, from this thread, it’s clear that even informed Julia users seem to have higher expectations. I can see this having a rough “launch day” from outsiders who think v1.0 means Julia has a debugger with jetpacks on it, static compilation with a fancy GUI, and every library is bug-free. Of course you can’t handle it all, but is there a good way for us to help make sure people understand what 1.0 will and will not be? For example, a Julialang blog post?
1 Like
Yes, there will definitely be a blog post to accompany Julia 1.0 which will explain to anyone reading it what the release means and what the future holds (stabilization and improvements to tooling, libraries and the compiler).
3 Likes
I’m wondering if a post should come sooner, basically saying “this is what’s in store and how we’re looking at 1.0”. Sharing your JuliaCon roadmap talk is probably the same thing though.
I think it’s sufficient to make sure that the blog post is ready when the release is and make the blog post be the release announcement instead of having multiple things that end up getting posted on HN/Reddit in bits and pieces.
1 Like
Experience tells that how a community talks about a 1.0 release (or a 4.0 for example) and how it should be interpreted does not change the way the general public sees it. (For those that do not get the reference, the too early 4.0 release of KDE was a PR disaster and broke much of its momentum)
This approach would be the wisest. A 1.0 release with too many problems (in the basic ecosystem) will get a lot of critisism and people trying and leaving regardless of how it is explained …
12 Likes
+1 on the 0.7 stable update phase.
1 Like
I am fully with Stefan here. 1.0 should focus on stabilizing the core. All the remarks about that we want to have a nice experience for all the people using Julia for the first time with 1.0 are valid and we should ensure that all packages are fully ported once 1.0 is announced. Lets do this by a long beta phase (3 month) where we Julians are all using 1.0 beta as if it has been released.
I thing important for 1.0 is Pkg3 and a mechanism for “default packages”. We have seen various peaces moving out of base which is really good. For nice “first time experience” it would be helpful though, to pull some packages in for the binaries that are downloaded.
10 Likes
Stefan, thanks for clarifying, it makes perfect sense to focus on API and library stability first.
In the 1.0 release announcement, perhaps you could add a mini-roadmap that mentions the main high-level future improvements planned for 1.1 so at least everyone knows the Julia developer team is aware of remaining limitations and plans to address them.
In any case, thanks for all your work, I am a happy 0.6.0 user 
1 Like
PR events, press reviews, etc. are ephemeral. Backward compatibility is forever.
1 Like
Well, until 2.0 that is…
1 Like
Yeah. But for whom?