+1 to everything David said. And yes, we should put out an official statement on this subject. Julia has absolutely been released on four and very nearly five occasions: 0.1, 0.2, 0.3, 0.4 and any day now, 0.5. These are not alpha releases, nor are they unstable. They are very solid and usable. The pre-1.0 numbering of these releases (see, that's the word) are simply an indication that we *will* change APIs and break code in the relatively near future – before 1.0 is out. We could have numbered these releases 1.0, 2.0, 3.0 and 4.0, but (to me at least), there's an expectation that a 1.0 release will be supported for *years* into the future, which would leave us supporting four-five releases concurrently, which simply isn't realistic at this point in time. Once Julia 1.0 is released we *will* support it for the long term, while we continue work towards 2.0 and beyond. But at that point the Julia community will be larger, we will have more resources, and releases will be further apart.
Aside: Swift seems to have taken the let's release major versions very often since they are already on a prerelease of major version 3.0 (and maybe that's better marketing), but to me having three major releases in two years seems a bit crazy. Of course, Swift has a very large, effectively captive audience. Julia is likely to follow the Rust approach, albeit with a *lot* less breakage between pre-1.0 versions. Issues you may have had with Juno don't really have anything to do with Julia, although there's an argument to be made that pre-1.0 numbering of the language is a good indicator that the ecosystem may be a little rough around the edges. Once Julia 0.5 is out, there will be a stable version of Juno released to go with it. On Tue, Sep 13, 2016 at 1:19 PM, Chris Rackauckas <[email protected]> wrote: > I agree that there are some qualifiers that have to go with it in order to > get the connotation right, but the term "unstable but usable pre-release" > is just a phrase for alpha. It's not misleading to characterize Julia as > not having been released since the core dev group is calling v1.0 the > release, and so saying pre-1.0 is just a synonym for "pre-release". Being > alpha doesn't mean it's buggy, it just means that it's alpha, as in not the > final version and can change. You can rename it to another synonym, but > it's still true. > > Whether it's in a state to be used in production, that's a call for an > experienced Julia user who knows the specifics of the application they are > looking to build. But throwing it in with the more stable languages so that > way someone in a meeting is like a stand-in ("hey guys, we can try Julia. > It should be faster than those other options, and should be hard to learn, > what do you think?"), that has a decent change of leading to trouble. > > And I think not being honest with people is a good way to put a bad taste > in people's mouths. Even if lots of Julia were stable, the package > ecosystem isn't. Just the other day I was doing damage control since there > was a version of Juno that was tagged which broke "most users'" systems, by > most users I mean there was an "obvious" fix: look at the error message, > manually clone this random new repository, maybe check out master on a few > packages > <http://stackoverflow.com/questions/39419502/cannot-start-julia-in-atom-loaderror-argumenterror-juno-not-found-in-path/39420874#39420874>. > You want to use the plot pane? Oh just checkout master, no biggie. > <http://discuss.junolab.org/t/plots-jl-in-atom/714/11> If someone is > trying to use Julia without knowing any Git/Github, it's possible, but > we're still at a point where it could lead to some trouble, or it's > confusing since some basic features are seemingly missing (though just not > tagged). > > When you're talking about a drop-in replacement for MATLAB/Python/R, we're > talking about people less familiar with all of this software development > stuff who have a tendency to confuse warnings (like deprecation warnings) > as errors, not realize their install is Julia v0.3 that they played with > one day from along time ago which is why the documentation isn't working, > trying to use a feature they see mentioned on a Github issue which requires > checking out a development branch but still on the release, wondering where > the documentation is for things like threads (and being told to just check > the source code), accidentally using deprecated / no longer developed > packages because they were pointed to it by an old StackOverflow post. > These aren't hypothetical, these are all things I encountered in teaching a > Julia workshop and beginning to spread it around my lab / department. None > of these problems are difficult to overcome, but if you say Julia is as > easy to use right now as those other languages, > non-software-development-oriented > users will quickly encounter these simple problems and it may leave a bad > taste in their mouths. > > "I tried Julia but I couldn't get Juno to install" > "Did you set the julia path either as an environment variable or inside > the julia-client package?" > "No, I don't know what the julia path is. Anyways, let me know when it > actually has an 'auto-install' since I want to be able to use an IDE, but > have it simple to setup" > > That's too common right now. People think a "developed" language means a > 1-click installed IDE to a language where they can use the same script a > year from now without any errors or warnings, and right now that's not > offered. Don't get me wrong, I love Julia and use it for everything now > because it is high quality, not buggy, and works well. But I would not say > it's not alpha. > > I too would like to hear the core devs weigh in. I presented my side, but > am willing to toe the party line if there is one. > > On Tuesday, September 13, 2016 at 9:39:09 AM UTC-7, David Anthoff wrote: >> >> I find this characterization of julia as “not released” and “alpha” >> really not helpful. To the casual reader these terms signal low quality and >> lots of bugs, and in my experience (after 2.5 years of heavy use) those are >> the last two things that come to mind with respect to julia. On the >> contrary, I think the quality of the julia builds at this point can easily >> compete with things like Python or R (in terms of bugs). >> >> >> >> I think the correct characterization of the pre-1.0 builds is that julia >> hasn’t reached a stable API, i.e. you need to be willing to live with >> breaking changes coming your way. That is a VERY different thing than a >> buggy alpha release! >> >> >> >> There is a large group of julia users out there that use julia for “real >> world” work. It is really not helpful for us if julia gets an undeserved >> reputation of being a pre-release, buggy thing that shouldn’t be used for >> “real work”. Such a reputation would question the validity of our results, >> whereas a reputation as “hasn’t reached a stable API” is completely >> harmless. >> >> >> >> Also, keep in mind that there is julia computing out there, which is >> feeding the core dev group. They have customers that pay them (I hope) for >> supported versions of julia, so it seems highly misleading to characterize >> julia as not released and not ready for production. Heck, you can buy a >> support contract for the current released version, so in my mind that seems >> very much released! >> >> >> >> I think it would be a good idea if the core julia group would actually >> put a definitive statement out on the website for this topic. There are a >> couple of devs that at least from the outside seem close to the core group >> that have made statements like the one below, that to any sloppy reader >> will just sound like “stay away from julia if you don’t want a bug riddled >> system”, and I think that really doesn’t square with the message that e.g. >> julia computing needs to put out there or with the state of the language. I >> think a good official position would be: “Current julia releases are of >> high quality and are ready to be used for ‘real world’ work. Pre-1.0 >> releases will introduce breaking API changes between 0.x versions, which >> might require extra work on the users part when updating to new julia >> versions.” Or something like that. >> >> >> >> Cheers, >> >> David >> >> >> >> -- >> >> David Anthoff >> >> University of California, Berkeley >> >> >> >> http://www.david-anthoff.com >> >> >> >> >> >> *From:* [email protected] [mailto:[email protected]] *On >> Behalf Of *Chris Rackauckas >> *Sent:* Tuesday, September 13, 2016 9:05 AM >> *To:* julia-users <[email protected]> >> *Subject:* [julia-users] Re: Julia Users and First Customers >> >> >> >> 1. Jeff Bezanson and Stefan Karpinski. I kid (though that's true). It's >> the group of MIT students who made it. You can track the early issues >> and kind of see who's involved. >> <https://github.com/JuliaLang/julia/issues?page=348&q=is%3Aissue+is%3Aclosed> >> Very >> early on that's probably a good indicator of who's joining in when, but >> that only makes sense for very early Julia when using means also >> contributing to some extent. >> >> >> >> 2. Julia hasn't been released. Putting it in large scale production and >> treating it like it has been released is a bad idea. >> >> >> >> 3. The results advertise for itself. You go learn Julia and come back to >> your lab with faster code that was quicker to write than their >> MATLAB/Python/R code, and then everyone wants you to teach a workshop. Also >> packages seem to play a big role: a lot of people come to these forums for >> the first time to use things like JuMP. >> >> >> >> 4. Julia hasn't had its first release. >> >> >> >> Keep in mind Julia is still in its alpha. It doesn't even have a beta for >> v1.0 yet. That doesn't mean it's not generally usable yet, quite the >> contrary: any hacker willing to play with it will find that you can get >> some extraordinary productivity and performance gains at this point. But >> just because Julia is doing well does not mean that it has suddenly been >> released. This misconception can lead to issues like this blog post >> <https://blog.staffjoy.com/retro-on-the-julia-programming-language-7655121ea341#.w1bggaw78>. >> Of course they had issues with Julia updating and breaking syntax: it's >> explicitly stated that Base syntax may change and many things may break >> because Julia is still in its alpha, and so there's no reason to slow down >> / stifle development for the few who jumped the gun and wanted a stable >> release yesterday. It always ends up like people complaining that the >> alpha/beta for a video game is buggy: of course it is, that's what you >> signed up for. Remember that? >> >> >> >> Making sure people are aware of this fact is a good thing for Julia. If >> someone's not really a programmer and doesn't want to read Github issues / >> deal with changing documentation (a lot of mathematicians / scientists), >> there's still no reason to push Julia onto them because Julia, as an >> unreleased alpha program, will change and so you will need to keep >> up-to-date with the changes. Disregarding that fact will only lead to >> misconceptions about Julia when people inevitably run into problems here. >> >> >> On Tuesday, September 13, 2016 at 7:55:51 AM UTC-7, Adeel Malik wrote: >> >> I would Like to ask few questions about Julia that I could not find it on >> the internet. >> >> >> >> 1) Who were the very first few users of Julia ? >> >> >> >> 2) Who were the industrial customers of Julia when it was first released? >> Who are those industrial customers now? >> >> >> >> 3) How Julia found more users? >> >> >> >> 4) How Julia survived against Python and R at first release? >> >> >> >> It's not a homework. Anyone can answer these questions or put me at the >> right direction that would be perfect. >> >> >> >> Thanks in advance >> >> >> >> Regards, >> >> Adeel >> >>
