
Julia 0.5 release - boromi
https://github.com/JuliaLang/julia/blob/master/NEWS.md#julia-v050-release-notes
======
3JPLW
A better link is:
[https://github.com/JuliaLang/julia/blob/release-0.5/NEWS.md](https://github.com/JuliaLang/julia/blob/release-0.5/NEWS.md)

Better yet, wait for the official announcement once binaries are compiled and
posted for download. I believe there will be a blog post to go along with it,
too.

~~~
KenoFischer
Yes, there'll be an official announcement in a little bit. Tagging is just the
first step (we haven't even added the release metadata to the tag on GitHub
yet).

------
tomrod
Excellent news! I look forward to reading over the release notes.

Edit: this is a game changer for me:

> Support for multi-threading. Loops with independent iterations can be easily
> parallelized with the Threads.@threads macro.

------
jmde
This could either be brilliant or a total nightmare:

"Support for arrays with indexing starting at values different from 1. The
array types are expected to be defined in packages, but now Julia provides an
API for writing generic algorithms for arbitrary indexing schemes (#16260)."

Originally I thought total nightmare but now I'm not sure.

~~~
Avshalom
Pascal and Ada have had arbitrary indexing for decades. It's been fine.

~~~
StefanKarpinski
And Fortran, where it works fine. Perl lets you change the array index offset
but everyone warns you that your computer will reach out and slap you in the
face if you do. As is often the case, the devil is in the details.

~~~
Avshalom
In perl is it APL style where it changes the index for the entire world (until
changed again) or is it Fortran/Pascal style where you are expected to declare
the lowest/highest index per array?

~~~
PeCaN
APL-style with a global index origin ($[ in Perl, à la ⎕IO in most APLs).

------
sndean
Is Julia 1.0 still scheduled for approximately Summer/Fall 2017?

I really like/liked Julia, but some things breaking between 0.2 and 0.4 made
me use it a bit less.

~~~
rspeer
I used Julia a bit in the same time span, and I was frustrated with the
breakage, but I also saw a lot of things that clearly needed breaking changes.
I'm glad they're happening.

Until now, [a, b] meant "concatenate a and b if they're arrays, make a
2-element array otherwise". This struck me as both annoyingly inconsistent and
as a failure to think recursively.

Now it's always a 2-element array, possibly an array of arrays. And that's a
huge change in syntax, and it's for the better. I look at many things in the
0.5 release notes and they're fixes to specific pain points I had. This has me
paying attention to the language again.

------
dschiptsov
Arguably, it is better numpy based on multimethods, but it is far from being
polished as Python 3.5+ On the contrary it suffers from the kitchen sink
syndrome, with process of continuous adding of stuff instead of continuous
clarification and refinement, which characterizes a good Python 3 language.))

But there is a lot of enthusiasm.

~~~
papaf
I think that you are missing the big picture.

To you it is a better numpy/python, to me it is a faster/cleaner/more
parallelizable version of R, to some people it is a cleaner/faster version of
Matlab.

This could be seen as a "kitchen sink" approach but it also is very useful
when you want to get things done. My gripes about Julia are really minor
considering how young and ambitious the project is.

~~~
dschiptsov
Yes, you are right. It is a better R. I haven't thought of R because I
consider it as being nothing special in terms of design of programming
languages.

------
mathieutd
Are there large speed improvements from the previous version?

~~~
3JPLW
Yes, in many areas:

* Higher order functions now specialize on (and possibly even inline!) passed functions

* Anonymous functions are now fast, too

* Fused broadcasting can avoid intermediate allocations and only make one pass through the array

* User-extensible bounds checks allow custom array types to opt-in to skipping bounds checking, enabling SIMD-ification of some for loops

That said, compilation times may take a bit longer due to the LLVM upgrade…
but this resulted in an even stronger push towards better performance in many
other areas.

------
ceyhunkazel
A feature request, Anaconda partners with Intel and includes MKL default.
Could you do same for Julia and add MKL default at least in version 1.0 so no
manual work needed?

~~~
tavert
See
[https://github.com/JuliaLang/julia/issues/18374#issuecomment...](https://github.com/JuliaLang/julia/issues/18374#issuecomment-245108175).
Open-source Julia builds also need to support non-Intel processors and
architectures, and operating systems where MKL isn't available.

If you have a specific operation where MKL is noticeably faster than OpenBLAS,
report it. OpenBLAS can always be improved if they have specific workloads to
target.

~~~
ceyhunkazel
Thanks for the comment, I understand why it is not option.By the way I do not
understand why I received downvotes.

~~~
tavert
Probably because a hacker news comment isn't the best place for a feature
request about using a proprietary library and comparing to a commercial
distribution of a different language.

By the way, Julia partners with Intel as well, but on things like adding
multithreading support to the language, and developing auto-parallelizing
compilers
([https://github.com/IntelLabs/ParallelAccelerator.jl](https://github.com/IntelLabs/ParallelAccelerator.jl)).
Improved support for building Julia with MKL and Intel's C and Fortran
compilers is something that Intel would probably like to collaborate with us
on as well, but not much has happened there officially yet (these are
different groups within Intel).

~~~
ceyhunkazel
Keep up the good work Julia team.

------
qwertyuiop924
I haven't thus far been interested in Julia. Unless you're into high-level
math, it didn't seem to provide much value, and it did weird stuff with
arrays, and wasn't Lua, which gets a free pass for being amazingly well
designed in all other respects (arguably, it was well designed in that one as
well, but it makes all the array math a pain).

I don't know, maybe it's great. Maybe I should reconsider. But then again,
it's strongly typed, which isn't usually my sort of thing (I'm not working
with a team, and my programs haven't devolved into chaos yet, so with no
empirical data either way, I'll take my favorite)

~~~
jhbadger
I'm not sure what you mean by "high-level math". It isn't a symbolic language
like Mathematica for mathematics research but something along the lines of R
for data analysis. The strong typing isn't just there for discipline, but
efficiency in execution.

~~~
qwertyuiop924
Yeah. But it's definitely optimized for mathematical usage.

~~~
Recurecur
Since programming is fundamentally mathematics (grin) that means it's a
"general purpose language". There's nothing whatsoever preventing it from
being a first-class string manipulation language for instance.

Granted, the emphasis has been on applied mathematics. I think in the longer
run it will branch in several directions, one being realtime simulation - and
then on to games. It is close to C++ efficiency (plus or minus) already, and
it will only get better.

I haven't looked into Julia's GC implementation in detail, but I'm hopeful
that with a little effort it's easy to avoid "stop the world" GC collections.

~~~
JoeAltmaier
That old saw is getting dull. Because something can be described by
mathematics, does not make it mathematics. Else the whole universe would be
mathematics.

Programming is the art of getting a particular machine to do something you
want. You may use math to get there (like in accounting or swimming) but its
fundamentally a task that's performed by skilled people.

