Next words are just my humble opinion (from “nobody” in Julia community) and I am open to change my mind!
Something similar to this, that Julia has some performance issue or not excellent user experience or lack of functionality could be seen relatively often. (problems that have issue open several years are relatively often too)
The next milestone (planned as 1.0) is for language stability - means no breaking changes for some (longer) time. I feel that it is not version prepared enough for general public audience as general purpose language yet. It is more version for package creators to start working more seriously or to start creating packages…
Next+1 milestone (planned as 1.1?) needs to focus on performance issues and package ecosystem improvement.
There is a little problem that if it will bring bigger performance in some part of language it could bring necessity to rewrite some part of code in packages too (read: brings some kind of breaking change).
What we want is to propagate Julia and releasing 1.0 is good opportunity for advertising. But it is also responsibility to not bring version which could get negative critic.
My humble question (just question I am not sure what is better): couldn’t be good to name next milestone 0.7 (+breaking change tabu) and wait to next+1 milestone for name it 1.0?
Or (this is probably same but maybe more acceptable to thinking about) not announce 1.0 too soon after 0.7?
Schematically:
0.7 - version for package/library creators. For early hackers (or people who see big potential). (“Hacker time investment rating” B-)
1.0 - version for general audience (conservative hackers (significant benefit is present in some domain), BBB+)
…
1.x (1.1?) - version for selling products based on Julia ((significant benefit is present in some domain), A)
…
1.y - version for Julia domination (great benefit is present everywhere, AAA++)
To give a more helpful answer: If you search a little here and on github you will quickly find the numerous places where this has been discussed already, and acquaint yourself with the arguments.
The problem is that there’s no end to improvements, especially performance ones. We shouldn’t rush 1.0 without being relatively satisfied with that release, since as you say many people are going to judge the language on that occasion. But we can’t indefinitely push back that event either, because many users have also been waiting for the stabilization of the language. Remember that version 0.1 has been released in 2012.
There will be alpha and beta 0.7 releases, with some time before 1.0 so that packages can be ported, which will ensure that new users testing Julia for the first time when 1.0 is out will have a relatively smooth experience. But the porting period can’t last for six months like a standard release.
This is besides the point. Julia isn’t a CAS, it’s a programming language. So of course it doesn’t have specialized methods for factorizing matrices of big rationals. It can be used to build a CAS though, like Nemo. That’s hard to do before 1.0 because the syntax can change at any time. Instead, it needs 1.0 so somebody can build a big CAS, knowing that the syntax won’t change under their feet every month.
I do agree that it would be a very good idea to wait a “long time” (by some definition thereof) between 0.7 and 1.0 so that things seem as stable as possible to new users once Julia is tagged as 1.0. That said, judging from 0.6, I think the language is in a really good state and both the core Julia devs and many package devs have done an amazing job getting things in good shape in a relatively short period of time. I think that the issue that will scare off the most people right now is the slowness of plotting, which has been discussed ad nauseum on this forum, but that doesn’t really seem like a core Julia problem to me anyway.
The slowness of Plots could be solved without changes in base Julia, as you mention. The only thing that could help would be to clarify a bit what’s going to happen for conditional dependencies, but from what I understand the plan is to always rely on glue modules. As a side note, with dot overloading in Julia it should become possible to use PyPlot with the exact same syntax as in Python, so there’s a good solution even for people that are very sensitive to start up time.
off-topic It’s only the first plot that is slow. With Revise a part of Julia there shouldn’t be any reason to constantly restart one’s session. At which point the problem goes away.
I was looking at newsletter published 03 Feb 2017. Julia 1.0 was planned (forecasted?) 2017 – Q2 & Q3.
Now is feature freeze and it seems that 0.7 (alpha+beta+release) could be 2018 Q2(?) and probably 1.0 (if transition period will be shorten to 3 month) 2018 Q3?
The whole Plots.jl thing is a good example of how 1.0 discussions get the “chicken and egg” problem wrong though. The reason why nobody worked on it for a long time is because nobody knew what conditional deps would look like in Julia 1.0. If we don’t have a feature freeze, we might as well keep waiting to see if something changes with conditional dependencies before the whole internals are re-done to match the current state of Julia. This is why no one touched it in v0.5, v0.6: because everyone was waiting to see what would be correct for 1.0. With 1.0 coming out, we can finally see how conditional deps have shaped out (answer: there’s no answer coming soon), so we can actually work on it.
Trying to wait to stabilize the language until core packages are stable just makes it incredibly difficult to build anything. With DiffEq I probably had to spend about 2 weeks getting everything from v0.5 to v0.6 (including some PRs to upstream dependencies, and then the whole thing with Iterators.jl). v0.6 to v0.7 seems like an even bigger change (especially to get rid of all of the hacks around features added), so I’d expect at least the same amount of upgrade time. Also note that my updating has to start late: upstream deps need to be fixed before I can even hope to fix DiffEq (since if dependencies fail to precompile, well…), so there’s quite a long lag time after release before everything is stable again. I am planning on blocking out about 3 weeks to just work on upgrading codes (i.e. not much academic work in this period)… (note that this includes all of the subsequent bugfixes that inevitably have to happen in the week or so after a big change) it’s fine for now but can’t keep happening.
The moral of the story is, we need 1.0 in order to more efficiently get work done. I am happy things will stabilize. But we need to treat the 1.0 release like it is: it will break things. It will be painful for a bit (of course upgrading will introduce bugs!). But this is the same as playing a game on its release date, or installing a new version of Windows the first day it comes out. If your someone that needs things to be stable, you will be disappointed if you use a gigantic new release on the first day.
I think it’s all about expectation management. Expecting the code to be compiled the first time it is called because that is how Julia can get its awesome speed and generality. I don’t think that’s too much to ask for from any reasonable scientific programmer.
I’ve “embarrassed” myself a few times trying to show people how fast Julia is and ended up waiting for huge precompilations due to an update…
It is definitely not a show-stoper for a user that already now Julia, but I really whish all the pre-compilation was done right after the Pkg.update().
Sorry I don’t understand. Are you telling that feature freeze phase will take several month or something similar?
I agree with everything. We have to politely ask people not to make review at that time!
I could not agree here. Maybe open source non-profit games… Or from developer who wants to shrink its market share.
no comment
I am trying to use master. And was thinking about trying to start package - dbapi for oracle (I am still not sure if it is not too big work or it is worth to do it though)…
I think Julia should launch version 1.0 ASAP, a lot of non-cs users are waiting to see it. For many of them, it is kind of risky to invest in a language that has not reached 1.0 version.
When Larry Ellison was marketing his company’s first software, he decided to name it version 2.0. The logic is straightforward, you want your product to look mature and reliable.
PS:
I personally think that the not-so-good user experience partly comes from Juno and Atom editor. After I switch to VS Code, everything gets quite smooth. My humble advice would be that: spend more resources on VS Code plug-in; make its own IDE (just think about Shiny and Sparklyr of R,
without RStudio, is hard to imagine their getting so popular).
Please no offense! I don’t want to blame big good work which is done! I am just trying to say truth about people and their expectation what good user experience is.
And you probably have to admit that many times after Pkg.update() definitely != one time.
No. The alpha phase for Julia will probably take around a month (if previous releases are indicative to it). Many packages will upgrade, but not everyone can block out time in that month to do free open source work! So there’s like a 2 month lag time (at least from previous releases) where you’ll run into packages which haven’t updated, or at least throw a bunch of deprecation warnings still. After that it generally is fine. But yes, upgrading isn’t easy, especially when it’s unpaid work.
Have you played any AAA on its release day? There’s a patch the day of the release, that night, the morning after, etc. getting all of the bugs people find. Or there’s an open beta which attempts to have enough prepaying users do the same thing. It’s just what happens with complex software: users have to find bugs.
I have had similar experiences but I learnt to rehearse any code I will show other people who just want to see SPEED!