
Julia Computing Granted $600k by Moore Foundation - one-more-minute
https://www.moore.org/newsroom/in-the-news/2015/11/10/bringing-julia-from-beta-to-1.0-to-support-data-intensive-scientific-computing
======
kriro
At first glance Julia looks excellent. Glad to see money going to a project
that makes sense :)

I guess Python is "the competition" so here's my thoughts on that competition
(from knowing fairly little about Julia). From my limited experience Python is
actually easy enough to grasp for most scientists without a programming
background so I'm not sure the "easier" argument is what should be focused on.
At the "lower end of the spectrum" (that is not super hard data crunching
and/or less affinity for programming) there's social sciences, psychology,
marketing, economics etc. and they use a variety of higher level tools (the
pesky SPSS) for their routine tasks and are usually willing to invest time for
more data crunchy activities (often R but Python is common as well in say
economics with data-crunchy models).

The big attraction of Python (for me) is that you don't just get the data
crunching but also the boilerplate you'll need around it (data normalization,
stroing stuff in databases and getting it out, turning your models into simple
web-apps etc.) \+ IPython notebook and distributions like anaconda make setup
and quick experimention fairly simple.

If I were to give advice to someone entering science I'd certainly suggest
"learn python". However...the more languages we have the better, MATLAB makes
me cringe for multiple reasons. Go Julia :D

~~~
maxerickson
IPython notebooks have gone multi language:

[https://jupyter.org/](https://jupyter.org/)

[https://blog.jupyter.org/2015/04/15/the-big-
split/](https://blog.jupyter.org/2015/04/15/the-big-split/)

I think Julia was one of the early alternate languages.

~~~
julienchastang
Out of curiosity, can you have multiple languages in one notebook with the
output of one cell, in say Python, be input for a second cell in Julia or R?
(emacs org-Babel allows for this -- a feature I use often.)

~~~
maxerickson
I just googled it, I don't know a lot about Jupyter, but yes:

[http://blog.dominodatalab.com/lesser-known-ways-of-using-
not...](http://blog.dominodatalab.com/lesser-known-ways-of-using-notebooks/)

[http://ipython.readthedocs.org/en/stable/interactive/magics....](http://ipython.readthedocs.org/en/stable/interactive/magics.html#cell-
magics)

------
jamesdutc
This is great news for Julia!

As a long time Python user, I disagree with the insinuation of competition
between the two communities. In fact, I've met all of the core developers of
Julia and of the major Python data science projects, and they see each other
as fellows and colleagues!

For example, last year at PyData NYC, Stefan Karpinski gave the following
talk, titled 'Julia + Python = \N{heavy black heart}'

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

This past week, at PyData NYC, Stefan Karpinksi also shared the stage with
Andy Müller (scikit-learn) and Jared Lander (author of R for everyone) to
discuss the future of machine learning with the audience and addressed how the
various tools, languages and communities fit together.

In fact, most people may not realise, but Julia, Jupyter, IPython, numpy,
pandas, matplotlib, &c. are all fiscally sponsored projects of the same
501(c)3 non-profit, NumFOCUS (which is the organisation that also runs the
PyData conference series)!

[http://numfocus.org/projects/index.html](http://numfocus.org/projects/index.html)

------
mdcfrancis
This is great news for Julia.

As a person who has spent the best part of year coding almost exclusively in
Julia (I work in finance, we were one of the main sponsors of JuliaCon, though
these are my personal thoughts) I want to chime in a little.

To get to 1.0 many of the cons in the language will be solved and there are
plans in place for much of this.

I never cease to be surprised by the brevity of code to solve complex
problems. Something which would be hundreds of lines in Java/C++ often turns
into 50 or so lines of much more readable code.

When asked to describe Julia I struggle but end up this way 'I can make Julia
'dance' like no other fast programming language' though to be fair modern JS
is pretty close for many tasks.

The parametric type system is to me the strongest part of the system - I
describe it simply as 'templates that work', it is ridiculously powerful and
(to me) is the most compelling reason to learn Julia.

I personally find even at 0.4 it is very usable even for tasks which are not
math. Though the run time is currently fairly heavy.

So congrats to the Julia team.

~~~
Nrpf
"many of the cons in the language will be solved"

Can you elaborate on this?

Re type system, how does it compare to python in use?

~~~
mdcfrancis
I'm not the best placed person to answer about Python, my background is
primarily C++/Java and functional languages. The types in general get out of
the way. The ability to specialize behavior by types makes for some very
interesting patterns and for a module writer add a huge amount of power. For
the user of the module they rarely see the types.

The cons, top three from the top of my head, implicit array concat ( going in
0.5 ), String types ( going soon ), anonymous function performance ( gone by
1.0 )

None of these are show stoppers, but they do sometimes fall into the category
of surprising. The core dev are very aware of the issues and if you look at
the road map for 1.0 many are either well on their way to being fixed or are
scheduled to be resolved.

------
jarmitage
For anyone interested in trying to get to know Julia (like me), I've found
these talks useful as a starting point:

Introduction to Julia - Part 1 | SciPy 2014 | David Sanders -
[https://www.youtube.com/watch?v=vWkgEddb4-A](https://www.youtube.com/watch?v=vWkgEddb4-A)

Get To Know JuliaLang - Guest Talk by Co-Inventor Viral Shah -
[https://www.youtube.com/watch?v=OC3hsct63Ok](https://www.youtube.com/watch?v=OC3hsct63Ok)

If anyone can recommend other resources that would be appreciated.

~~~
chappi42
Here is a good short blog post: [http://www.nowozin.net/sebastian/blog/the-
julia-language-for...](http://www.nowozin.net/sebastian/blog/the-julia-
language-for-scientific-computing.html)

------
memming
This is great news for Julia and the scientific computing community in
general. MATLAB doesn't scale, and python solutions are too scatter brained
for me.

~~~
jbssm
I actually, more and more think that python is an excellent language for
science.

The only issue is that, when it comes to numerical computation, there is only
"one right way to do it", which goes against Python philosophy. Meaning,
either you do it while using vectorial operations mostly everywhere, or it's
just too slow to work.

The only real advantage I see in Julia, is that it doesn't constrain you to a
specific way to think about calculations. You can think about them in a
vectorial way (which is not always possible) or you can just use an iterative
approach. Both work fine.

This is what I mainly expect to get from Julia, but we must admit that the
inertia behind python and it's excellent libraries for numerical computation,
make it hard to change to Julia.

~~~
r0muald
> The only issue is that, when it comes to numerical computation, there is
> only "one right way to do it", which goes against Python philosophy.

But ... This is actually one of the pillars of Python:

 _There should be one-- and preferably only one --obvious way to do it_

<[https://www.python.org/dev/PEPs/pep-0020/>](https://www.python.org/dev/PEPs/pep-0020/>)

~~~
jbssm
My bad... I sometimes mix Perl and Python philosophy.

~~~
jkyle
> I sometimes mix Perl and Python philosophy.

That's like mixing up Vulcans and Romulans. Very dangerous indeed.

------
outlace
OOP is "weird" in Julia compared to Python and others and first time users may
find it off-putting, but just power through and eventually you'll realize just
how awesome multiple dispatch is and the lack of traditional classes. It's a
more functional style that is very powerful (and in my opinion, more readable)
in scientific computing.

------
hellofunk
One of the reasons to consider Julia, as noted in the article:

>its flexibility and high performance (comparable to C)

This is one of those points that is so rare to see in new, high-level
languages, and quite welcome in the world of high-iteration numerical
computation.

------
Gravityloss
I hope they can have it accessible to people who are not that interested in
fancy computer science concepts, but rather want to read in data, do
computations, and write out data/graphs again. Without massive boilerplate or
hair pulling.

It seems to be really hard to create smooth user experiences for the common
use cases of such complex products. I think people have been trying to oust
Matlab for 31 years or so.

Disclaimer: I haven't checked Julia for a few years. Requiring hand reloading
of files after editing and no native graph support were a few major problems
for a workflow back then.

~~~
yiyus
The scientific community is not going to adopt any new language until most
used idioms can be easily found in a quick search and copy-pasted. It is
extremely difficult to arrive there.

I totally agree that having dynamic dispatch in the first position of the
features list, for example, does not help. But, in my opinion, it is ok for a
pre-1.0 language. That is what makes exciting seeing some external help to
release a stable version.

~~~
CyberDildonics
What's wrong with dynamic dispatch?

~~~
yiyus
Nothing at all. But, if Julia takes off, I would not expect it to be the main
selling point.

It can be a very interesting feature for somebody into language design, but
the average Joe working in a lab is not going to learn a completely new
language and rewrite all his Matlab code because of it. Most probably, he has
not idea what it is or why he would want it.

It was an example of how, at this point, it seems like the web site is more
directed towards language developers than potential users.

~~~
elcritch
Actually, I think the main page is directed toward those scientific users who
create their own custom projects and/or libraries. This also goes back to your
earlier point in that early in a language evolution you need more library and
package creators so you can have a broad ecosystem for the more day to day
programmers. One example of this need, is the creator of the fftw library (a
cornerstone fft implementation in C) wrote several popular packages for Julia.
I think there's a talk he gave at the 2014 JuliaCon.

In this regard, multiple dispatch is actually a huge selling point! I've
written in Fortran 90 code, C, Python, and enjoyed most of those languages.
There is something unique about being able to pull up the source code for
almost every operator/function in the language, implemented in that language.
Fortran has this, but is much more statically oriented and difficult for quick
scripting. Python, well I'm hopeful pypy keeps building momentum. Or perhaps
Pyrhon ported to web assembly, in more pure Python.

------
harikb
I still don't 'get' the language. I still have to think like running
interpreted code. Definition of methods, scope, is a bit confusing/error-prone
for my taste.

[http://docs.julialang.org/en/release-0.3/manual/parallel-
com...](http://docs.julialang.org/en/release-0.3/manual/parallel-
computing/#code-availability-and-loading-packages)

I am still hopeful. I will give another look at it soon.

~~~
idunning
There are definitely some scope issues with the distributed computing
functionality, see e.g.
[https://github.com/JuliaLang/julia/issues/13649](https://github.com/JuliaLang/julia/issues/13649)
for a general tracking issue (also, that is the 0.3 version of the manual).

------
tianlins
Julia certainly does have several features worth being excited about: calling
C without wrappers, macros, good JIT performance. But I think what really
matters is the ecosystem. With python, there is tons of libraries such as
Numpy and Scipy for scientific computing, django for web backend, etc. It is
unclear whether the community will embrace Julia fully within the next few
years.

~~~
IndianAstronaut
>With python, there is tons of libraries such as Numpy and Scipy for
scientific computing,

I do remember early on when this wasn't the case. Especially when comparing it
to Matlab or R. I was discouraged by one professor from learning it. But time
has proved otherwise. Julia will likely be the same.

~~~
timholy
If you compare Julia and Scipy at similar points in their evolution, Julia is
far ahead of where Scipy was. And that's while the language itself is still
evolving.

------
KenoFischer
It seems like I should mention that we (Julia Computing) are actively hiring.
If you think what we're doing is interesting and would like to join in, please
do reach out!

~~~
Redoubts
Any particular positions, or is this one of those "you'll know if you're able"
kind of things?

~~~
KenoFischer
Well, last time I posted something like this I think I made it sound way too
narrow, so I'm trying overly broad this time, to get people who are interested
to get in touch, because even if we don't have anything for them at this very
moment, we might in the near future.

To narrow down, what we're looking for in the immediate future, anybody with
interest in core language development, compilers, tool chain support, etc.
Additionally, we will probably be hiring for our applications development team
very soon, so if you're interested in data science, stats, etc. and like
working with people on solving their challenging problems, please do reach out
as well.

~~~
dangjc
Please put effort into a good IDE that leverages the type system! I've been
using Julia for two years now, and there's enough code to navigate through
that it's becoming difficult to maintain. I'm really starting to miss Java/C#/
even C++ IDEs where you can easily jump to a definition or get a non-fuzzy
autocomplete. Not to mention the refactoring support of the IntelliJ products.
For a language that promises to handle both the high level and the low level,
it really is not scaling well with codebase size. I've also been reassessing
my needs and realizing that only about 20% of my codebase is quantitative
code, and then with most of the work being sent off to raw CUDA or Theano. So
I'm actively considering a better tooled language. I love how expressive Julia
is, but that may be getting in the way of tooling. One issue that would help a
lot is return type declarations
([https://github.com/JuliaLang/julia/issues/1090](https://github.com/JuliaLang/julia/issues/1090)).
Return types would dramatically ease creation of IDE plugins.

~~~
KenoFischer
That's definitely very high on the TODO list!

------
plinkplonk
As someone who worked briefly with Julia (My "standard" tools are Haskell and
C) this is really awesome news. Way to go Julia team!

------
mtw
Are there small or big tech companies using Julia in production? I'm
interested in use cases outside of research labs

~~~
idunning
StaffJoy ([https://www.staffjoy.com/](https://www.staffjoy.com/)) are using
Julia for staff schedule optimization, and a large multinational is using it
for train schedule optimization. Its also in use (at least on a trial basis)
in the financial sector.

It'd still be a fairly large risk to develop something built-to-last on Julia
at this point, so not really the best time for most companies to jump in
unless something about Julia really solves a problem they are having.

------
tadlan
Will julia ever be popular for general computing and Web stuff? It's s till
fast for non scientific use cases, has multi threading (in master) and is
getting go like channels.

~~~
wbhart
I think it will be interesting to see what happens with WebAsm. If Julia
targets this at some point (it is based on LLVM, so there is a chance of
this), then I think it will start to look quite attractive for various use
cases that it isn't currently cornering.

~~~
Nrpf
Makes sense. But regardless, the core language is better than go in almost
every way (as far as I know)... and it has python like syntax. I wonder if
thats enough.

~~~
wbhart
I personally think Julia is technologically superior to a number of popular
languages, with a voracious appetite for even more smarts. But you are right
that this isn't necessarily enough.

Based on what I've seen so far, I think Julia could eventually break into the
Tiobe top 20 languages (it's currently in the top 100). On the other hand, I
think this is plenty. As a language currently aimed at (admittedly fairly
large) niches that would be an outstanding outcome.

It also makes it fun to work with as a language. It's not just more chicken.

------
sandGorgon
whenever there is R compared to any other analytics framework, the number one
advantage is cited to be CRAN. And the counter is always that "hey python has
wheel".

Does anyone think that a dedicated package site for analytics libraries is
what is needed ?

From the R documentation:

 _In the simplest form, an R package is a directory containing: a DESCRIPTION
file (describing the package), a NAMESPACE file (indicating which functions
are available to users), an R / directory containing R code in .R files, and a
man/ directory containing documentation in .Rd files_

But a python wheel is considerably more complicated.

~~~
onalark
Have you looked at conda and [http://anaconda.org](http://anaconda.org)? We
spent a lot of time curating the most important Python packages for data
science into the Anaconda distribution, and conda packages are a great format
for distributing complicated software.

~~~
sandGorgon
this is pretty cool and I think you are on the right track here. but here's
the same question here - are you making the process of package _creation_ much
easier ?

Because I suspect until you acquire mindshare among the academics (who
distribute their research as R code), this will be difficult to scale.

------
gct
I pray they make a breaking change before 1.0 and make it zero based

~~~
icholy
Amen. As stupid as it may sound, this is the only reason I haven't gotten into
it ...

~~~
superbatfish
You're not the only one.

OK, this might sound even _stupider_ , but I feel _betrayed_ by the fact that
otherwise good, technical people would voluntarily make such a major mistake,
and then defend it so vigorously in the face of so many complaints.

~~~
superbatfish
OK, clearly some Julia fans down-voted my comment, perhaps because they
misunderstood it. I was trying to say something about human psychology. We can
admit that it is silly, but we can't pretend that it doesn't exist. This may
be a bigger deal than they realize.

Programming languages are used primarily by humans, which means they must be
designed with human psychology in mind. Today, Julia would have (even) more
community support if not for this seemingly inconsequential decision. The fact
that it seems to be succeeding anyway is largely in spite of, not because of,
this design choice.

------
progman
Congratulations!

By the way, where can I find perf.h in the benchmark suite? perf.c is there
but perf.h seems to be missing.

~~~
StefanKarpinski
perf.h is generated by the makefile in that directory.

~~~
progman
Thanks, I'll try it.

------
g0wda
I love Julia. This is great news! :)

------
Nrpf
Is this going to get us better dataframes and nullable integration?

~~~
ViralBShah
Yes, that is certainly part of the plan. We will be releasing details in a few
weeks.

~~~
elcritch
While some people love dataframes, in both Python and Julia, they feel
constraining to me.

Does this mean there will be more features limited to DataFrames?

For example, Gadlfy is nice in many ways but by not using Dataframes it means
I have to do my own colors for each data I plot. Some of the statistics
features in GLM seem to rely heavily on DFs as well.

Dataframes could be much more useful more broadly if the interface was more
consistent, better documented (e.g. still haven't figured out how to
instantiate with half my data).

Basically, null-ability is pretty useful feature in many fields, not just
statistics. Will the plans include any items to help generalize nullability?

~~~
stillyslalom
Generalized nullables exist in Base already
([http://docs.julialang.org/en/release-0.4/manual/types/#nulla...](http://docs.julialang.org/en/release-0.4/manual/types/#nullable-
types-representing-missing-values)), unless you had something else in mind.

~~~
elcritch
My question really was ambiguous and more to do with subtle frustration with
limitations of the current DF library and the dependence of various nice
statistical features in GLM, or plotting in Gadfly, that rely on DataFrames.
It's not just nullable types (and also I believe the Nullable arrays in DF are
tuned for performance with linear algebra operations, which may not be true
for general Nullable arrays). You can get to the features in other ways, but
it's easiest to use DataFrames and the documentation is written for DF's.
However I think the documentation, scope of functionality for DataFrames, etc
is not complete enough for me to quickly use it day-to-day. So I basically
just put everything back into arrays and do a couple of custom functions to
get my work done. Julia makes this great, but it'd be better to not need to
and MATLAB still has many more "easy" functions along these lines.

