
My favorite things that are coming with Julia 1.0 - oxinabox
https://white.ucc.asn.au/2018/06/01/Julia-Favourite-New-Things.html
======
ScottPJones
The creators of Julia have been focusing on technical, numerical, scientific
computing first, however, the language was always intended to also be a good
general purpose programming language (which it is) [I was lucky enough to
attend Jeff Bezanson's Ph.D. thesis defense at M.I.T. 3 years ago - and was
able to ask him that question there]. I used to be a full-time C/C++
programmer, focused on performance of large systems, however, since learning
Julia I haven't had to go back to writing C or C++ even once in over 3 years,
since I can write even the sort of low-level code I typically do in Julia,
faster and easier than in other languages, and get the same performance.

~~~
nur0n
I'm strongly considering Julia as an alternative for C/C++. A few questions if
you don't mind: * How does Julia's GC play into the performance
characteristics of these systems? * What tools does Julia offer for fine-
grained control of memory? * It appears that Julia uses a rich runtime, do you
notice it "weighing down" on performance? * Do you ever feel the need to drop
down to C/C++ for hot code paths?

~~~
ScottPJones
I do have to be aware of the GC, and try to use techniques to avoid lots of
allocation. I haven't needed much in the way of fine-grained control of
memory, what sorts of things were you looking for? A lot of that "rich
runtime" (i.e. including the kitchen sink for linear algebra stuff) has been
moved to stdlib, but still packaged with Julia, but even before, it really
didn't seem to affect performance except for slowing down the time to build
julia (esp. on the Raspberry Pi!). In over 3 years, I've never needed to write
anything in C/C++ (except a couple of times I wrote something out in C just to
demonstrate the Julia was generating as good or better code (and I mostly
write rather low-level stuff). I have it in mind to learn Rust, which I think
would be much better than either C or C++ for that sort of stuff (to make a
small robust library of functions for some hot code paths), and it integrates
well with Julia (using ccall), but the day that Julia's performance hasn't
been good enough as not yet come, at least not for me.

~~~
nur0n
Thank you! I was not looking for anything in particular. Julia's design is
everything I've been craving from a language; good performance seemed too good
to be true. Due to never having worked on large systems, my judgement is of
limited use. Your feedback convinced me to take a serious look at Julia.
Looking into the discussions regarding Julia's implementation (so cool that
they are easily accessible on GitHub/Discourse) convinced me to commit to
learning it.

EDIT: grammar

------
twic
> It will be interesting to see exactly how _nothing_ and _missing_ play out
> in-practice. I feel like if all things go well, then in most circumstances
> operating with a _missing_ should return a missing (i.e. properation), and
> operating with a _nothing_ should throw an error (Much like a
> NullReferenceError).

We all know that having a null value in your language is a mistake, but i have
to admit that it had not occurred to me that the fix was to have _two_ null
values.

~~~
masklinn
> We all know that having a null value in your language is a mistake, but i
> have to admit that it had not occurred to me that the fix was to have two
> null values.

Javascript is even better as it has 3 (null, undefined and NaN, and while NaN
is available in most every language it is pretty common in JS as its
conversion APIs tend to return NaN instead of error).

~~~
petre
How is 3 null values better than one? Fortunately Dart has fixed this
nonsense.

~~~
jimbokun
(That's the joke.)

------
parvenu74
What is the target market or prime use case for Julia? What makes it better
than alternatives? I've _heard_ of this language but haven't studied it; I'm
trying to understand if this is more of a niche language or something which
could see more mainstream adoption like Go or Rust.

~~~
drjesusphd
It's for high-performance numerical work. The language of choice in scientific
computing is still Fortran, and for good reason. Julia has become my go-to
language for new codes, but Fortran still has its place. In particular, Julia
is slow to be adopted by supercomputers.

~~~
StefanKarpinski
Slow but not non-existent:

[https://juliacomputing.com/case-
studies/celeste.html](https://juliacomputing.com/case-studies/celeste.html)

It's tough to crack the old school high-performance computing world, which is
very slow to change programming tools, but Julia is the first and only high-
level dynamic programming language to do it. Now that it's been shown to be
possible to exceed a petaflop/second in Julia without having to write any
gnarly, low-level C++ code, I suspect we'll start to see it happening more in
the future.

~~~
hpccurious
Did Celeste rely on pure Julia code to achieve its petafloppiness or were
there other libraries at play, say Intel MPI, OFED and IB drivers, RDMA
functionality, any custom C++ at all, etc? How much in the way of low-level
distributed bit twiddling was part of the development of that application?
Would anyone not named Keno be able to write a similar application?

~~~
StefanKarpinski
Libraries like LAPACK and MPI were standard C/Fortran ones wrapped from Julia
but all of the custom application code was written in Julia. No doubt the
application would not have been so successful without the extremely talented
team that worked on it—including Keno, who was described by the project PI as
a “one man army”—but that’s true of any record-setting supercomputing project.

------
noobermin
I'm surprised the author didn't touch on the massive changes to Pkg. Now Pkg
is a lot more like npm, allowing for "project" level packages rather than
requiring global packages.

~~~
oxinabox
Good point, that is _huge_ , I was intending to mention it as the start (and
have done so now).

It like the getfield overloading and a few other things really deserve a post
of their own, so I wasn't going to try and push them into this one.

------
dyu-
Great ffi perf too! From the benchmark over at github.com/dyu/ffi-overhead,
julia is on par with luajit.

~~~
ChrisRackauckas
Wow! Thanks for sharing! Julia and LuaJIT's JITing strategy really shine here,
calling shared libraries faster than C itself!

------
_jordan
Phenomenal language. compiles applications to a single binary which makes it
super convenient to move around environments

~~~
oblio
How? Everything I've read about Julia seems to show that you're supposed to
pass the source code files around.

[https://medium.com/@sdanisch/compiling-julia-binaries-
ddd6d4...](https://medium.com/@sdanisch/compiling-julia-binaries-ddd6d4e0caf4)
-> notice that's a third party package.

~~~
ninjin
Indeed, which comes with its own advantages and disadvantages. As someone that
has to always care about performance, Machine Learning, I am very happy not to
have to worry about dependencies not being compiled to take advantage of the
latest and greatest CPU instructions on a specific box in a very heterogeneous
cluster. Now, you could just compile it all on each deployment, but something
as large as say TensorFlow takes ages and not everyone gets to enjoy having
great devops at your beck and call.

~~~
oblio
I'm not sure I understand what you mean: you prefer compilation on the target
machines or you prefer a static binary?

~~~
ninjin
Compilation on the target machine, in my case. Performance trumps portability
for me, but I can totally see why this is not the case for everyone.

~~~
oblio
In theory that can be solved with the best of both worlds: have the runtime
and JIT in the final binary. That way you still get easy deployment with 1 big
file and high performance after the JIT warms up, which should be fast.

I think it's just a problem of manpower on the Julia developer side.

~~~
ninjin
I wholeheartedly agree, one could also note how this is Java-esque. My hope is
that someone far more well-versed than me in this area will find the time and
push for it. On that note, one wonderful thing about Julia is how easy it is
to contribute to the core language since it is written in Julia. It really is
amazing to see people from so many disciplines come together to push a
“language for science as a whole”.

------
adrianhel
I had a look at Julia like 2-3 years ago and thought it seemed really nice to
use.

The performance is of course also awesome.

So I hope we get more traction for Julia as a general purpose language. But
for now I'm sticking with Node.

------
a-dub
Can you run it with the plotting libraries loaded and have whos() return in
less than 10 seconds yet?

I was excited about v0.6 but then when I learned it took >15s to do whos(), I
completely gave up...

~~~
kescobo
Depending on which plotting package you use. Plots.jl itself is pretty slow to
get started still, though there are ideas on how to improve that.

That said, once you're up and running, plots (and everything else) are super
snappy. When I'm doing plotting stuff, I'm usually doing it interactively, and
when I'm scripting it, it's because I'm plotting hundreds or thousands of
things (and then the startup time is vanishingly small).

~~~
a-dub
I first thought the whos() issue was some JIT thing... but no, after multiple
runs it was still taking 10s of seconds.

For context, I come from using MATLAB interactively. When doing that kind of
work, the MATLAB 'whos' command is like /bin/ls, it's hard to do much without
it.

Is there a different command in julia for showing all numerical
arrays/matrices/tensors in memory and their dimensions from the repl? whos()
seems like another direct analog of MATLAB, but maybe there's something better
that isn't unreasonably slow?

~~~
ivirshup
I'm a little late to the party, but I think something like this should do the
trick:

    
    
      [names(Main) typeof.(eval.(names(Main)))]

~~~
a-dub
_runs crying back to MATLAB_

------
sidcool
And we are struggling to connect Julia to Postgres DB.

~~~
StefanKarpinski
Have you looked at
[https://github.com/invenia/LibPQ.jl](https://github.com/invenia/LibPQ.jl)?
The folks at Invenia are very sharp and generally produce excellent, reliable
packages, so I would expect this to be of high quality. The primary author,
Eric Davies, in particular, is a well known high caliber Julia contributor :)

~~~
sidcool
I am using it, but it's quite inconvenient. The return types are wrong.
Documentation is sparse. I would like contribute to it.

~~~
3JPLW
Please do! Not only are the folks at Invenia technically talented, they're
also really kind and wonderful. I'm sure I'm not speaking out of turn to say
that I think they would very much appreciate bug reports, API feedback, and
especially doc and code contributions!

~~~
sidcool
I have started with documentation and coffee samples that I m trying. Let's
see where it goes with code contribution. I am especially trying to
efficiently convert the hideous NamedTuples to DataFrames.

------
hellofunk
Would anyone recommend using Julia for things like web servers? Python is used
for web servers, and is slow. But Julia doesn’t really seem marketed to that
application domain, despite that I would expect it to do a better job with the
demands on a server due to its performance.

I know web frameworks exist for Julia, but I’m wondering how practical it is
to actually use this language for that purpose?

~~~
goatlover
If your only requirement is performance, then you'd probably be better off
using Go or Node. My guess is you would use Julia for a web server when it
ties into other things you're using Julia for.

But maybe I'm wrong here. It seems that "use the right tool" turns into use
Python or JS or Excel for all the things.

~~~
oblio
I guess you’re not up to date: Excel is getting JS scripting soon and most
likely Python scripting not long after that :D

~~~
goatlover
Haha, well then! World conquest is surely right around the corner with that
combo. Maybe allow for some Rust plugins and have it run on blockchain, just
to be on safe side.

------
hellofunk
Honest question, just how fast is Julia anyway? Because performance is
typically the main reason anyone would want to use it over alternatives. A lot
of people justify Julia because, as noted in other comments, it is both high-
level yet claims to be nearly as fast as C:

> "Julia is the fastest modern open-source language for data science, machine
> learning and scientific computing...with the speed, capacity and performance
> of C, C++..." [4]

That's a bold claim! And there is much evidence to the contrary. I often find
that the language falls into a similar trap of many other languages where the
creators are evangelists not quite sharing the whole picture. Writing fast
Julia code is not always a pleasant experience as you often need to fight the
easier idioms. It is marketed as fast, but really, how fast is it?

[0] [http://www.zverovich.net/2016/05/13/giving-up-on-
julia.html](http://www.zverovich.net/2016/05/13/giving-up-on-julia.html)

"What’s disappointing is the striking difference between the claimed
performance and the observed one. For example, a trivial hello world program
in Julia runs ~27x slower than Python’s version and ~187x slower than the one
in C."

[1]
[https://www.ibm.com/developerworks/community/blogs/jfp/entry...](https://www.ibm.com/developerworks/community/blogs/jfp/entry/A_Comparison_Of_C_Julia_Python_Numba_Cython_Scipy_and_BLAS_on_LU_Factorization?lang=en)

"We can code in Julia in a way similar to Python's code. However, that code is
slower than it should. One way to speed Julia is to take into account the
Fortran ordering it uses by looping on j before looping on i in the second
loop. We also add decorators to speed up the code."

[2] [https://www.codementor.io/zhuojiadai/julia-vs-r-vs-python-
st...](https://www.codementor.io/zhuojiadai/julia-vs-r-vs-python-string-sort-
performance-an-unfinished-journey-to-optimizing-julia-s-performance-f57tf9f8s)

"...comparing R's sorting speeds to Julia's is not the complete story, even
though on the surface R appears faster, and from a users' perspective, (once
the data is loaded) R is still the king of speed."

Stackoverflow has quite a few user posts [3] from folks trying to get their
code to perform at the advertised speed vs popular alternative languages. It's
not so easy.

[3] [https://stackoverflow.com/questions/20613817/julia-julia-
lan...](https://stackoverflow.com/questions/20613817/julia-julia-lang-
performance-compared-to-fortran-and-python)

[4] [https://juliacomputing.com/](https://juliacomputing.com/)

~~~
stochastic_monk
This is absolutely correct. The benchmarks they claim are misleading, and
under fair conditions, Julia simply isn't the speed/efficiency solution they
market themselves to be.

I think that the ML community's decision to write core operations in C or C++
and provide Python wrappers is the way to go about it if you want the
flexibility of scripting.

~~~
eigenspace
That is absolutley false. Look closely at the 'benchmarks' shown in the above
article and tell me if they are at all compelling. They measure Julia's
startup time and compilation time. IF you wanted to compare Julia to C there,
you'd want to include the time it takes to compile your hello_world script.

Julia's performance optimizations have to far been mostly focused on intensive
numerical computations where the startup time and compilation time are merely
a constant overhead that are irrelevant to high performance numerics.

~~~
stochastic_monk
No, it's not. My comment is unrelated to startup and the issue in this article
but more generally about Julia as a language of failed promises.

The biggest issue with the standard Julia benchmarks is that they're not using
what would be optimal C code to compare against.

In addition, if you look at the Julia issues on GitHub, you'll find hundreds
of performance regressions where code performs more than 10 times as slow as
what they expected/claimed at one point. It's not reliably fast, even when
written by Julia experts/developers.

~~~
Certhas
This is ridiculous. On top of eigenspaces comment, the promise was never that
any odd Julia code would be fast. You can write untyped/dynamic code and that
will be faster than Python but not near C, or you can put a little work into
ensuring type stability (from experience this is easier than writing in C from
the start, especially as you already have a working prototype that you are
iterating in the same language) and you get excellent results.

~~~
stochastic_monk
I was very careful to state this the people writing the code I was talking
about were Julia experts/developers, not just anyone writing arbitrary Julia
code.

When you're doing that much typing, you might as well write C or C++.

~~~
ninjin
Okay, with this comment your comment on preferring C++(11?) and pybind11 [1] I
think I am finally getting your angle. Let’s see if I can bridge the
perspectives.

If I am reading you correctly, you are a library builder, an infrastructure
creator, and comfortable caring about the bottom line when it comes to
performance. You most likely prototype an algorithm in some high-level
language, ensuring that it works, then push it down into C++ in order to make
it scale to cool problems, lastly you may create bindings to a higher level
programming language so that others without your C++ acumen can benefit from
your labour. A lot of great code is written this way, some that I rely on in
my day-to-day work would be OpenBLAS, TensorFlow, and PyTorch.

I can only really speak for myself, but I know that there are many like me, we
are researchers and to us code is only incidental. We are judged based on our
ability to churn out as many papers and results as possible, in as little time
as is humanly possible (ever wondered why academic code can be absolutely
awful?). We rarely know the structure of the solution a-priori, rather, we
start throwing techniques at things and try to make the experiments run. At
some point, a (wild?) performance bottleneck appears and we just want to get
around it as soon as possible. Now, some like myself have been in the
Python/Cython world for years and you can get around a lot of bottlenecks this
way. However, it comes at the expense of additional boilerplate and mastering
which parts of the Python programming model you must throw overboard, not to
mention how you make your Cython code interact with pure Python code from
libraries that others have written. This is where Julia shines, it allows you
to much easier go between this “productive” and “performance” mode, to me,
this is worth its weight in gold. It is not for everyone, but if I ever have a
law named after me I would be happy if it was “Nothing is for everyone”.

[1]:
[https://news.ycombinator.com/item?id=17206370](https://news.ycombinator.com/item?id=17206370)

~~~
stochastic_monk
You’re exactly right. Thank you for bridging the gap in perspectives. I used
to do a lot in cython but found that the glue code was taking more effort than
writing the whole application in C++.

~~~
Certhas
Glad that someone managed the translation. Another note: I'm a trained
mathematician, I'm not afraid of a type system (nor are the physicists I work
with). In fact I was missing one dearly in Python. If that was all that was
needed to write C++ instead of Python we all would.

Yet that's how Julia looks to us: Python + a sensible Type system.

------
d--b
Where are we compared to then ([http://www.zverovich.net/2016/05/13/giving-up-
on-julia.html](http://www.zverovich.net/2016/05/13/giving-up-on-julia.html))?

~~~
eigenspace
Theres a discussion on that post in another thread below, but suffice to say
the julia community is pretty exasparated with the constant need to respond to
that post when its main source of the speed claims was to measure the
perofrmance of a hello world program in julia and included the compilation and
startup time in the benchmark.

Thats a deceptive and unhelpful 'benchmark', especially when the C++
compilation time was not included in its benchmark. Julia compilation and
statup times are slow if you are expecting the feel of the Python interpreter,
however, julia's compilation and statup time add a finite, constant overhead
to its preformance and so are completely irrelevant for high performance
numrical computing.

If you were wanting to spawn many julia instances and make them execute a
single command then exit, yes julia would be a terrible choice of that (unless
you turn of compilation and use its interpreter or statically compile your
program) but for the most part measuring startup time just isn't relevant
unless it takes a minute or something absurd.

In julia the only libraries I know of that take a minute to load are plotting
libraries (once you make your first plot the library is blazing fast again)
and thats been considered such a big issue that a new plotting library Makie
is well under way which is supposed to be fully statically compiled in julia
in order to slash the first time to plot.

------
abakus
One thing I always dislike about julia is the .+ .* .< ... all those dots for
element-wise operations. It is inherited from Matlab, but is a bad design
because more common usage should have shorter operators.

~~~
ssfrr
Whether elementwise or linear algebra operations are more common depends on
your use case. I’m personally super happy not to need to write np.dot(A, b)
when I could just write A*b, or a’b for an inner product, which matches the
math and will do the right thing with complex numbers.

------
Bromskloss
Ooo, it must be zero-based indexing! Right?!

~~~
oxinabox
Zero-based indexing was kinda mentioned in the post. About indexing with
`begin`

------
mafm
Upvote because I think this is the 1st time a posting from the ucc website has
made the HN front page.

------
wirrbel
Julia always was one of the languages I wondered whether I should have a
closer look at (do python data-science stuff mostly, so it is an interesting
project). However, reading Dan Luu writing about his experiences with members
of the Julia community
[https://danluu.com/julialang/](https://danluu.com/julialang/) I try my best
to not get anywhere near it. Directly cited:

    
    
        Update: this post was edited a bit to remove a sentence about how friendly
        the Julia community is since that no longer seemed appropriate in light of
        recent private and semi-private communications from one of the co-creators
        of Julia. They were, by far, the nastiest and most dishonest responses I've
        ever gotten to any blog post. Some of those responses were on a private
        discussion channel; multiple people later talked to me about how shocked
        they were at the sheer meanness and dishonesty of the responses. Oh, and
        there's also the public mailing list. The responses there weren't in the
        same league, but even so, I didn't stick around long since I unsubscribed
        when one the Julia co-creators responded with something bad enough that it
        prompted someone else to to suggest sticking to the facts and avoiding
        attacks.  That wasn't the first attack, or even the first one to prompt
        someone to respond and ask that people stay on topic; it just happened to
        be the one that made me think that we weren't going to have a productive
        discussion. I extended an olive branch before leaving, but who knows what
        happened there?
    
    
        Update 2, 1 year later: The same person who previously attacked me in
        private is now posting heavily edited and misleading excerpts in an attempt
        to discredit this post. I'm not going to post the full content in part
        because it's extremely long, but mostly because it's a gross violation of
        that community's norms to post internal content publicly. If you know
        anyone in the RC community who was there for the discussion before the
        edits and you want the truth, ask your RC buddy for their take. If you
        don't know any RC folks, consider that my debate partner's behavior was so
        egregious that multiple people asked him to stop, and many more people
        messaged me privately to talk about how inappropriate his behavior was. If
        you compare that to what's been publicly dredged up, you can get an idea of
        both how representative the public excerpts are and of how honest the other
        person is being._

~~~
hellofunk
I've seen that post as well, and often wondered if it was fair
characterization of overall Julia community (maybe it is), or is the result of
a single bad apple at the top that overshadowed an otherwise pleasant
community.

Unfortunately, it doesn't take much negative energy to spoil a community, even
if it comes from just one person. That it was a language co-creator is
troubling but not necessarily a reason to avoid the language if the rest of
the community is nice (which maybe it is, maybe it isn't).

However one thing I have noticed is that most language communities do tend to
follow an attitude set by the language creator(s). This seems to have played
out quite a bit for Clojure, Python, Elm, Elixir, and other languages where,
at least to me, the overall shared perspective of the community is closely
aligned to the personal attitudes and opinions of the language author(s).

~~~
ScottPJones
I don't feel at all that it's a fair characterization of the overall
community. I'm sure I've been the target of more of what Dan Luu experienced
than anyone else in the Julia community, from the same source, but I haven't
let that stop me from contributing as best I can to the community, by
answering questions (on Gitter and Discourse), helping with code, and by
contributing my own packages to help out in areas where I felt Julia needed
some extra attention. I also think that most of the community is more aligned
with the example set by Jeff and Viral. Both show great civility, patience,
and a willingness to listen to others, in my experience. Finally, with regards
to the person that both Dan and I have had problems with (and I have no
personal knowledge of that feud, that happened before I had discovered Julia),
I respect him a lot (even if he feels I "attack" him when I try to bring up
technical issues with code / designs that he's been involved with), I will
always be grateful for his role in creating Julia, I think he's a great
promoter of Julia, at conferences, etc., and he often has quite a lot of good,
well-thought out things to say on GitHub and Discourse.

~~~
wirrbel
Don't you ever wonder how many excellent contributions to Julia were not made,
because that person overstepping boundaries?

