
Julia 0.5 Highlights - one-more-minute
http://julialang.org/blog/2016/10/julia-0.5-highlights
======
preygel
Exciting to hear -- I have used Julia for prototyping, and have found it to be
excellent for that:

In my experience there are still some rough edges as compared to the Python
ecosystem (of course!), which together with the 0.x status make it impractical
for many production situations. However it is fantastic for prototyping
numerical code, the type system is a pleasure, and the JuMP mathematical
optimization library is a gem. Being able to have fast code be "first class,"
as opposed to the impedance mismatch of dealing with numba/Cython, feels great
and is a real boon for trying new things. Then, it is fairly straightforward
to port the final solution to whatever production language you use (e.g.,
Python with a sprinkle of numba).

~~~
baldfat
Really interested in why you would use a "faster" language in julia then move
to a "slower" language like Python or R?

~~~
preygel
Typically a mix of reasons:

\- Needing to interact with an existing codebase, and an existing developer
base. If everyone knows and uses Python and only a few use Julia, it is too
early to put Julia in production. If there are proprietary libraries, now may
not be the best time to commit to porting them to Julia.

\- Language and ecosystem stability. I started something on 0.4, and with 0.5
there were a raft of deprecations. If the code will live several years, that's
a support commitment with unclear value.

\- Library maturity. If I need to build a web app, read an Excel, read a CSV
with dates _quickly_ , consume a SOAP endpoint, etc etc in Python -- no
problem. With Julia I will mostly be fine, but am likely to run into _some_
cases that are not yet 100% there.

\- Most code does not need the extra performance, so once you have a fast
prototype as a performance target it is often not that hard to hit similar
performance with Python + numba/Cython.

Note for that last point: there _is_ a lot of value to not worrying about this
in the exploratory stage, and getting a performance target (for later
optimization) as a nice byproduct.

------
christophilus
TL;DR; This is a pretty big update. There are potentially breaking changes
(e.g. errors when calling ambiguous methods). And there are significant
performance improvements when dealing with functional-style programming
(lambdas, closures, etc).

~~~
StefanKarpinski
Errors when calling ambiguous methods are unlikely to be a big hazard – at
least we haven't found them to be. Most ambiguous calls are very unlikely to
actually occur, which is why that change makes a lot of sense.

The big breaking change is the array indexing one – that will very much
require adjusting multidimensional array code.

------
baldfat
5 years ago I thought for sure I would be using Julia today. (I mostly use R)
I have found that news tools have come into play that I haven't really felt
the need for a faster language then R for my work.

I'm interested in people's everyday use of Julia and how it has impacted your
workflow. I don't work with "Big Data" most of my data sets are bellow 100k in
size. Anyone using Julia for medium and small data sets?

~~~
StefanKarpinski
Not to be snarky, but we announced Julia in Feb 2012, which is less than 5
years ago. Unless you happened to be in the MIT class that used Julia in the
Fall of 2011, you're probably overestimating how long you've been following
the project.

If you're comfortable using R and the tooling and performance it offers, you
should probably keep using it. Julia isn't just about big data, but it does
tend to appeal to people who are struggling with problems that are
sufficiently hard that their old tools left them in a world of pain. That pain
may comes from size, complexity, CPU-intensiveness, or need for more language
expressiveness (a hard thing to define). In particular, Julia offers a unique
combination of productivity and speed for numerical work that can't be found
anywhere else.

~~~
baldfat
Okay 4.5 years :) I really was wowed by the promise of Julia and the road map
you presented for it, great job by the way. I just am surprised I haven't
picked it up yet personally. I have a feeling that my R ecosystem wouldn't be
as strong as it is right now if it wasn't for the friendly Julia competition
you have provided.

I guess I am seeking the one "pet project" that would get me to jump in and
give Julia a test drive.

Thanks for all your work even though I don't directly benefit from your work.

------
kibwen
Congratulations! As a Rust user, I'm always happy to see new programming
languages break into the field. :) However I am confused by this paragraph:

    
    
      > Julia’s LLVM version was upgraded from 3.3 to 3.7.1. 
      > [...] we’re very happy to be back to using current 
      > versions of our favorite compiler framework.
    

LLVM's current version is 3.9, is this a typo or are there problems that
prevent Julia from being used with any release newer than 3.7.1?

~~~
KenoFischer
LLVM 3.7.1 is a little less than 10 months old. Our RC period lasts for about
3 months, the start of which is the last point we'd have possibly upgraded
LLVM. Upgrading LLVM is a little bit of a scary prospect for us since we find
new bugs in every version (and fix them!), so though we considered moving to
3.8, 3.7 had been stable for a few months, so we didn't want to risk it.
There's currently a PR to bump LLVM to 3.9 for 0.6, so I'd expect 0.6 to be
released with LLVM 3.9.1.

~~~
kibwen
Cool, mostly I was curious if the show-stopping issues you were seeing were
actually fixed for good or whether 3.7.1 just happened to "accidentally" work.
:)

~~~
KenoFischer
Nothing accidental about it, it took quite a bit of work to fix all the issues
we had ;).

------
banachtarski
I'll be honest, giant factor speedups are awesome, and I always look forward
to writeups about the discovery process and such, but I'm of the opinion that
the presence of those optimizations in recent history means the software is
often many years from actual maturity and suitability for production usage.

Either way, looking forward to reading about where the optimizations
themselves came from.

------
krastanov
Can anybody explain the remark about LLVM towards the end of the post? What
were the difficulties of updating it, especially with respect the intermediate
versions?

~~~
3JPLW
If you're really curious, you can follow some of the breadcrumbs through the
"Activate LLVM 3.7" GitHub issue (which was originally started for version
3.5).

[https://github.com/JuliaLang/julia/issues/9336](https://github.com/JuliaLang/julia/issues/9336)

------
dvdplm
I love the detailed description of the changes made and the reasoning behind
it. Great read, thanks.

------
stewbrew
WRT julia's type system: I still don't get it. Is Julia dynamically or
statically typed? Are type errors detected at compile time (or since it's
jitted when loading a file) or at runtime (i.e. when the code is executed)? I
personally don't see much use in just another dynamically typed language that
gives me similar errors as R does.

~~~
StefanKarpinski
Dynamic: [http://stackoverflow.com/questions/28078089/is-julia-
dynamic...](http://stackoverflow.com/questions/28078089/is-julia-dynamically-
typed/28096079#28096079)

Julia uses its type system for:

\- self-documentation

\- reduction of boilerplate manual type checking that litters libraries in
dynamic languages

\- all those times you need to express the type of something, which happens
especially frequently in numerical code

\- performance

In the future, some "type linting" could be built into the standard library
since we can infer types for so much code, but it isn't the top priority.

------
christophilus
I'm curious to hear from people who are using Julia on a regular basis. What's
the UX like? I only looked at it briefly and was turned off by some things
(1-based indexing comes to mind). But I really liked other things (multiple
dispatch).

~~~
baldfat
1-based for statistics is a STRONG reason to use it. 0 based is ridiculous for
a statistics program and the reason why I left Python. I understand for
looping and the arras to be internally 0 but when doing statistics I should
have to use two different index.

~~~
n00b101
_1-based for statistics is a STRONG reason to use it. 0 based is ridiculous
for a statistics program_

Could you elaborate on that? What about statistics do you feel makes it
necessary to have 1-based indexing?

~~~
Fomite
My flippant answer: "No one is ever assigned Patient ID 0"

It's mostly about expectations. Users of statistical software, who may or may
not be programmers by inclination, use 1-based indexing. The program they came
from uses 1-based indexing (R, SAS, Stata, etc.). When you talk about data,
you rarely talk about the 0th observation. It's just a recipe for errors to
have to code switch between 0 and 1-based indexing.

------
gugagore
Why does the returned value (100, 100) consume 208 bytes?

~~~
simonster
The counter reports all heap-allocated memory, not just memory that persists
after the function call, and the description in the post doesn't look quite
right. The 208 bytes come almost entirely from calling the function from the
global scope. Inside a function, there would only be 16 bytes of memory
allocated on the heap, for the generator itself (which we desperately want to
get rid of, but that is still WIP) and the return value would live in
registers or on the stack.

~~~
jamii
> which we desperately want to get rid of

Would that be covered by
[https://github.com/JuliaLang/julia/pull/18632](https://github.com/JuliaLang/julia/pull/18632)
or is it a separate issue? I have some really ugly code that ought to be built
out of nested generators, but I can't afford the millions of heap allocations.

------
pklausler
Is there anything like Julia, but with strong typing and pure FP?

addendum: read 'static' for 'strong', please

~~~
jahewson
That depends on what "like Julia" means. It's not a functional language, so
the short answer is "no". Given that it lacks a true static type system and
supports macros it's philosophically LISP-like; notably the Julia compiler
includes a sizeable chunk of LISP code. But it's also clearly _not_ a LISP.

~~~
StefanKarpinski
I realize that your use of the phrase "functional language" seems to entail
having a static type system and purity, but most people seem to consider Lisp
to be the original functional language and it doesn't have either property. If
one considers Lisp to be functional then it seems like Julia should be as
well. Do you not consider Lisp to be functional? Real question, not a
rhetorical one – I'm trying to assess where people fall on this terminology.

~~~
pklausler
"Functional language" is ill-defined, hence my specific question about static
typing and purity. I would really like to have a language for scientific
computing that had good scalable performance as well as static types and
referential transparency.

~~~
StefanKarpinski
As far as I know, no such system exists. Strict static typing and numerical
computing are, I suspect, more at odds with each other than they casually
appear to be. The seemingly simple `+` operator is the most polymorphic and
overloaded function-like entity in many static languages (and often can't be
defined as a normal function for that very reason). And `+` doesn't hold a
candle to the polymorphism of array indexing and slicing, which is pretty
crucial for productive numerical work.

~~~
pklausler
Thanks for your reply.

Someday, Haskell will get a good matrix library, and then I'll be happy.

