Thanks for weighing in. I'll stick to your lingo: solid and usable, but not
with a guarantee of long term support until v1.0. That's what I've been
meaning by alpha (I mean I use Julia everyday because it's solid and
usable), but I won't continue to use that term because it seems to carry a
worse connotation than what I meant it to have.
Though I will say that when I talk of "Julia", I also am referring to the
package ecosystem (like how Python means Python + NumPy etc.). FWIW, most
of the issues I run into tend to be due to packages rather than base.
On Tuesday, September 13, 2016 at 1:00:10 PM UTC-7, Stefan Karpinski wrote:
>
> +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 <rack...@gmail.com
> <javascript:>> 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:* julia...@googlegroups.com [mailto:julia...@googlegroups.com] *On
>>> Behalf Of *Chris Rackauckas
>>> *Sent:* Tuesday, September 13, 2016 9:05 AM
>>> *To:* julia-users <julia...@googlegroups.com>
>>> *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
>>>
>>>
>
