
Julia v1.0 has been released - ellisv
https://github.com/JuliaLang/julia/releases/tag/v1.0.0
======
KenoFischer
We'll have a proper release blog post up in the morning.

~~~
sctb
OK, let's have the discussion then too!

~~~
KenoFischer
Thank you! People are always too closely watching our GitHub ;).

~~~
ellisv
and the live feed

~~~
waldir
For context, they mean the live video feed of JuliaCon 2018. Here's where the
release was announced: [https://www.youtube.com/watch?v=1jN5wKvN-
Uk](https://www.youtube.com/watch?v=1jN5wKvN-Uk)

------
photon-torpedo
The release notes for Julia 1.0 are rather empty at the moment. However, one
may refer to the release notes of Julia 0.7
([https://github.com/JuliaLang/julia/blob/release-0.7/NEWS.md](https://github.com/JuliaLang/julia/blob/release-0.7/NEWS.md))
which was released earlier today. Julia 1.0 is basically the same as 0.7,
except that all deprecated syntax/features have been removed.

------
sundarurfriend
Edit: It has happened!

Relevant pull request:
[https://github.com/JuliaLang/julia/pull/28521](https://github.com/JuliaLang/julia/pull/28521)

Video from Juliacon: [https://youtu.be/1jN5wKvN-
Uk?t=1h18s](https://youtu.be/1jN5wKvN-Uk?t=1h18s)

\---

~~Note that this is the first release candidate version[1]:~~

> As a prerelease, 1.0-rc1 should not be considered production-ready. It’s
> intended to give developers a chance to get ready for the release of 1.0 by
> trying it out and testing for issues. Most users should continue to use the
> latest release (0.6.4 at the time of writing) until 1.0 is fully released.

[1] [https://discourse.julialang.org/t/julia-v1-0-rc1-is-now-
avai...](https://discourse.julialang.org/t/julia-v1-0-rc1-is-now-
available/13008)

~~~
stellalo
It looks like this HN entry, however, refers to the stable 1.0 release

~~~
sundarurfriend
It's pretty weird, I'd assume it was a mistaken tagging except that the commit
[1] is very clear in its intent. I still don't think they'd suddenly have
decided to rush through it all and release 1.0 like this, so I'm still
assuming there's a mistake or misunderstanding here.

[1]
[https://github.com/JuliaLang/julia/commit/5d4eaca0c9fa3d555c...](https://github.com/JuliaLang/julia/commit/5d4eaca0c9fa3d555c79dbacdccb9169fdf64b65)

~~~
tavert
The annual juliacon is happening right now. So yes the last few weeks of this
release process have been very rushed. Only around 160 packages have made
releases that pass their tests using Julia 1.0.0 at the moment, out of 1900ish
total registered packages.

------
sleavey
Having never used it, I wonder, could Julia replace Python as the de-facto
standard in scientific computing and data analysis? What does it do well?

~~~
collinf
My only fleeting experience with Julia is in a Numerical Analysis Course three
years ago... but it has 1-indexed arrays so its good for scaring away all
people who are programmers before analysts/scientists!

Really though, I think it has a better type system and a syntax that
translates easier to mathematical expressions. Other than that, Python's
breadth of packages will be hard to overcome.

~~~
chriselrod
I know it is not the default, but this package has no overhead over the
default arrays according to recent benchmarks, and provides 0-indexed arrays:
[https://github.com/JuliaArrays/OffsetArrays.jl](https://github.com/JuliaArrays/OffsetArrays.jl)

I confess, not being the default is a big thing. I've definitely had times
where I thought "this would be easier with 0 indexed arrays", but it can then
be harder to commit to adding a dependency and making that change vs just
adding awkward looking "+1"s to all the indexes. Coming from math/science,
there's lots of times 1-indexing makes more sense / is more familiar. It's
normal there to start counting from 1, so it can be easier to translate.

~~~
phkahler
It's non uncommon in mathematics to index from zero as well.

------
montalbano
Currently at JuliaCon2018 where the new package manager was demonstrated this
morning, it looks absolutely wonderful.

~~~
ellisv
Did Stefan (or anyone else) mention how Pkg handles diamond dependencies?

------
vslira
Is Julia a decent substitute for non numerically focused tasks?

I’ve been thinking about learning a new lang recently, and while Julia does
seem to be a real alternative to python for analysis, I can’t see how
ergonomic it would be for simple (or convoluted, why not?) scripts.

The reverse keeps me from investing more time in Go (and Rust), though

~~~
chriselrod
ScottPJones uses it for string processing, and I have seen him comment on
hackernews a few times. He's a big advocate for using it for things other than
crunching numbers.

For scripts, the JIT overhead has gotten a lot better, and I think it will
continue to improve. The strategy is saving more so that it doesn't have to
get recompiled on launch. That currently doesn't happen for packages. Which
means while R and Python run much slower, they feel much snappier -- and will
be much faster if you're just running a bunch of short scripts that wont
amortize compilation. So in the short term, I wouldn't use Julia for speed.

Multiple dispatch and powerful meta-programming are two other major
highlights. Multiple dispatch can make for much simpler, cleaner looking
syntax, while often making it easier to remember too -- you only need one name
per concept. I briefly compared explicit SIMD vectorization in Julia and C
here: [https://bayeswatch.org/2018/08/08/matrix-multiplication-
kern...](https://bayeswatch.org/2018/08/08/matrix-multiplication-kernel/) were
I to change the vector size, all that'd take in Julia is changing the number
of elements, and it'll dispatch correctly. In C... I don't have too much
experience with object oriented programming which gives single dispatch, but I
like the separation of functions from objects, and freedom of dispatching on
any/all of the arguments.

If metaprogramming appeals to you, Julia makes that really easy compared to
many other languages, with things like the `@eval` macro or `@generated`
functions. Any sort of repetitive pattern that isn't easily expressed in array
operations can probably be handled pretty simply with metaprogramming. I gave
an example of `@generated` in the blog post with matrix multiplication
kernels, and a great example of `@eval` is:
[https://github.com/JuliaDiff/ForwardDiff.jl/blob/master/src/...](https://github.com/JuliaDiff/ForwardDiff.jl/blob/master/src/dual.jl)

In that link, ForwardDiff defines a gazillion function overloads for dual
numbers for automatic differentiation.

Being an interactive language, plus the helpful macro `@macroexpand`, can make
it easy to explore and figure out what's going on if you like playing with
that sort of stuff.

I've heard loads of great things about Rust, too. Hope this helps decide if
its worth looking at. My examples were all still analysis-focused, but that's
my experience.

------
peatmoss
In the past when I’ve poked around with Julia, I used Emacs Speaks Statistics.
If you’re familiar with using R in this context, you’ll probably find
developing and interacting with Julia to be quite easy.

If the Julia community could manage to get Julia support into RStudio, I think
we’d see a more accelerated uptake. I’ve heard rumblings that RStudio has at
least thought of supporting Python in RStudio (more than they do now with R
Notebooks). I can’t help thinking that if RStudio were to add support for an
additional language, that Julia might be a good choice.

All in all I’d prefer to do data things in Racket or another lisp, but Julia
feels good. I could see both the Python and R communities being tempted.
Here’s hoping!

~~~
jjoonathan
What parts of RStudio do you prefer over Jupyter?

~~~
peatmoss
I prefer many things about RStudio over Jupyter! I have two main issues with
Jupyter (Notebooks).

First, Jupyter Notebooks don't facilitate working with revision control very
well. Each time a notebook is saved, a new mess of JSON is belched out. I
think the path to collaboration via revision control should be as easy as
possible for analysts. This model of notebook is pretty hostile to making the
jump to collaboration.

By contrast, RStudio's "R Notebooks" (supports more than R) are human
readable, and git revisionable, with no loss of functionality as compared to
Jupyter Notebooks. This is the same model that Emacs's org-mode uses for a
document with embedded, executable code snippets.

Second, while Jupyter Notebooks can be an easy path for someone with no
computer experience to get started, it's very hard to scale the environment up
to writing larger analytic projects. The notebook model that Jupyter provides
doesn't allow you to escape the notebook without ditching the tools pretty
much completely and learning something entirely new.

By contrast, RStudio makes moving between notebook computing and more
traditional IDE support for R scripts very easy. A thing I have done that is
easy in RStudio (or Emacs org-mode):

\- start building a plain R script with just comments

\- convert to an R Notebook where I essentially add rich documentation

\- once things start to get unwieldy, I start to factor out code from my
notebook into more reusable project modules. I then let a notebook report be
the "tip of the iceberg" where I still have the write-up of my analysis and
embedded supporting evidence like plots and tabular summaries.

At this last evolution, my notebook is really just a UI for the outputs of my
reusable analysis code. If I want to take things further I can:

\- Move away from a notebook / document presentation of my results toward an
interactive application via Shiny.

I just don't see any way that Jupyter Notebooks are any easier than RStudio's
tooling. I also see that RStudio's tooling facilitates moving up and down
through different more or less technical interaction models. Jupyter Notebooks
by contrast are a brittle environment that pretty much dictates you stay
within their walls or learn something else entirely.

------
kgwgk
Looks a bit rushed, less than 24 hours after the release candidate.

~~~
stellalo
As far as I know, the 1.0 release only removes deprecated features from 0.7,
the previous “transition” release. So that probably didn’t require much
incubation

~~~
kgwgk
The previous "transition" release, which was published earlier today. At least
there was a whole week since the 0.7 RC1 version was released.

------
dg96
[https://youtu.be/1jN5wKvN-Uk](https://youtu.be/1jN5wKvN-Uk)

The moment, an hour into it

------
xyproto
I think they only prepared a tag for 1.0.0, while 0.7 is still the latest (and
very recent) release. I don't know why they do it this way, though.

~~~
FridgeSeal
1.0 is 0.7 with all the stuff marked deprecated/etc removed.

------
plg
Are there any demos of Julia for scientific computing? I found the
Documentation for Julia but are there any tutorial style demos?

~~~
chrispeel
A recent tutorial is at [1]. JuliaCon 2018 is happening now, and many talks
with tutorial content are going up on the Julia Youtube channel.

[1]
[https://www.youtube.com/watch?v=b5xvVyzUnXI](https://www.youtube.com/watch?v=b5xvVyzUnXI)

[2]
[https://www.youtube.com/user/JuliaLanguage/videos](https://www.youtube.com/user/JuliaLanguage/videos)

------
htor
congrats!
[https://www.youtube.com/watch?v=TZip_br_v3w](https://www.youtube.com/watch?v=TZip_br_v3w)

------
qop
The software release of the year, easily.

What an incredible journey the team has had this far. A very approachable
group of people involved with the project have tirelessly given their work to
the Julia language and finally, FINALLY the 1.0 is ready for consumption.

As if I wasn't psyched for this weekend enough already!

