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] <javascript:> [mailto:
> [email protected] <javascript:>] *On Behalf Of *Chris Rackauckas
> *Sent:* Tuesday, September 13, 2016 9:05 AM
> *To:* julia-users <[email protected] <javascript:>>
> *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
>
>
