
Why I'm Betting On Julia - mistermcgruff
http://www.evanmiller.org/why-im-betting-on-julia.html
======
kevinalexbrown
When out with friends recently, one of them mentioned how awesome Julia is. I
was surprised to hear someone talk about it, even from another person in
science. She turned and gushed about how awesome it was, how supportive the
community was, even though she was "not really someone who likes programming."
And she liked it so much she was telling her friends about it at a bar!

If you make a programming language that people who don't like programming love
enough to spread by word of mouth when not near a computer, which technically-
oriented people also love, that's a lot like the OSX terminal + nice GUI
blend.

That's a pretty rare thing. And for collaborative science it's pretty
important. Often, you'll have people in a bio lab who are very proficient in
their area of biological expertise, but who would be solving the wrong problem
by spending 2 years trying to become C++ hackers. On the other hand, there are
a lot of people who write computational libraries, but know they have to
translate them to matlab, or write a matlab wrapper and pray that their users
can get it to compile which might sound simple to folks here, but is _really_
frustrating for less computationally oriented people when something goes
wrong.

~~~
Pxtl
To be fair, there's also Python+NumPy and R in that space, not just Matlab.
Besides the "tinker with LLVM" thing, what does Julia offer that Python (or
Cython for speed)+NumPy does not?

~~~
simonster
Writing fast code in Julia requires less effort than it does in Python or R.
You don't have to drop down to Cython or Rcpp to get good performance. If you
write an algorithm in Julia the same way you'd write it in C, it will achieve
equal performance. If you write it the same way you'd write it in Python or R,
it may not be optimal due to the cost of memory allocation, but it's still
faster than Python or R.

Julia is more concise than Python. The language was designed to work with
multidimensional arrays; it wasn't bolted on afterwards. There is no
difference between a 2D array and a matrix; * always does matrix
multiplication and .* always does element-wise multiplication. There is no
awkwardness involving differences between NumPy arrays and Python lists.
Everything has a type, and you can make a multidimensional array that
efficiently stores values of any type. You can define your own types and
define how arithmetic operators act on them with a minimal amount of code.

Julia's type system makes writing efficient algorithms easy without
sacrificing any performance. If you define your own immutable type and define
your own operators on it, Julia can make those operators run as fast as they
would on ordinary values. In addition to general matrices, we have diagonal,
symmetric, and tridiagonal matrices. The same routines that work on general
matrices work on these as well with the same syntax, just more efficiently.

Julia uses multiple dispatch instead of traditional class-based OO. Methods
are not a part of the object; instead, they operate on the object. Different
methods with the same name can be defined to work on different types, or a
single method can operate on a set of types, but the functions it calls may be
implemented differently for each of these types. This is a better fit for
technical applications, where the data doesn't change much but the methods do.

Julia is homoiconic, which is more useful than this article makes it seem :).
It's easy to write code that writes code. If built-in language features aren't
enough to get good performance with concise syntax, you can write a hygenic
macro that does this for you.

~~~
wirrbel
To the rescue of numpy: A matrix from linear algebra and a 2D array are not
exactly the same. In Python they are different convertible types and I think
in practice it is hardly a drawback. That the multiplication operation is
overloaded in the Mathematical World with the same symbol as the "normal"
multiplication is unfortunate, numpys solution is as good as introducing two
different operators (with one being an awkward .*)

I love the multiple dispatch part about julia though.

My fear however is, that unlike Python, Julia will lack enough libraries,
especially on the unscientific part (GUI, databases, network, all the other
stuff you need).

~~~
StefanKarpinski
> That the multiplication operation is overloaded in the Mathematical World
> with the same symbol as the "normal" multiplication is unfortunate, numpy's
> solution is as good as introducing two different operators

The thing is that _the_ multiplication operation for matrices _is_ matrix
multiplication, not elementwise multiplication. When you apply a polynomial
like x^2 + y to matrices, you do not want to apply the polynomial elementwise
– you want to square the x matrix and add the y matrix to it.

~~~
lloda
Sometimes an array of numbers is just an array of numbers. The language
shouldn't presume too much about what you mean to do with them.

The moment you need an extra dimension (or anything other than 2 really)
Matlab's ‘everything is a matrix’ approach falls apart. Matlab is a toy
language in so many ways and this is just another one.

It's a pity that Julia adopted Matlab's pop matrix semantics instead of some
solid and general principles from APL or J. Even modern Fortran would have
been a better model for an array DSL. From what I've read of the Julia docs,
they actually want you to write loops. But Julia looks great otherwise. With
macros and a good compiler, maybe the array features can be fixed at some
point.

~~~
shele
Yes, adverbs, ranked matrix operator and some other parts of the APL/J
approach I miss a bit and find them tedious to emulate/avoid.

------
candybar
I really don't like the anti-intellectual tone of the beginning.

"The problem with most programming languages is they're designed by language
geeks, who tend to worry about things that I don't much care for. Safety, type
systems, homoiconicity, and so forth."

can be rewritten as:

"The problem with most software is that they are designed by computer geeks,
who tend to worry about things that I don't much care for. Information
security, thread safety, modularity, hardware acceleration, system design, and
so forth."

~~~
john_b
The language may have been grating, but as someone who also comes from more of
a scientific computing background, I read this as "I want a language to be a
tool that I can use to solve scientific and engineering problems with minimal
conceptual overhead due to minding language features." I read it as saying
"Finally, a language designed for someone like me," which I also find true
personally.

~~~
Beliavsky
"I want a language to be a tool that I can use to solve scientific and
engineering problems with minimal conceptual overhead due to minding language
features."

Among compiled languages, isn't that Fortran, especially since Fortran 90 on
have multidimensional array operations, like Julia, Numpy, and Matlab.

~~~
mrks_hy
It should read the other way round - Julia, Numpy, especially Matlab have
array operations like Fortran 90, since they are designed by people from that
background.

The problem with Fortran is interoperabality with other libraries; if you
leave scientific computing, you're basically out of luck. Writing a GUI is
just not going to happen. It is really fast, but it is also not as easy for
prototyping since it is also compiled like C. Finally, Fortran does have the
kind of stigma coming from older versions like 77 - and it's still really easy
to write REALLY bad and unmaintainable code with it if you're not minding the
newer language features. Especially OOP (since Fortran 2003) feels a bit
tacked on.

------
kibwen
I'm excited by Julia, but I don't think this article makes a very good sell.
It's neat that you can dump the generated assembly, but I'd rather see a
demonstration of a robust profiler so that I know which functions I need to
dump in the first place.

I also disagree that the popularity of Node stems from "getting disparate
groups of programmers to code in the same language". From what I've observed,
it's not that back-end programmers are suddenly giddy at the prospect of
getting to use Javascript on the server, it's that front-end programmers get
to apply their existing knowledge of Javascript to back-end development.

~~~
jjoonathan
I tend to agree with you about tools. I have yet to meet a language feature
that's more important than library availability, profiling, autocompletion,
documentation, debugging, etc. Then again, I don't face the script/C/CUDA
choice everyday (most of his detractors on this thread don't either, I'd be
willing to bet) so his circumstances are probably different enough to justify
a different priority list. His argument might be perfectly valid for the HPC
community which is a powerful constituency among academic programmers.

However, he _did_ address library availability, and that argument resonates
with me. I've never met a FFI I didn't come to loathe. I've had java, ruby,
and python FFI libraries fail to satisfy my needs despite half a dozen
bugfixes between them. What this man says about having to write wrappers,
despite abundant and loud promises to the contrary, is completely true. You
don't have to wander far off the beaten path before a typical FFI goes belly-
up. POD structs usually suffice (Sure, we support POD structs! Oh, you want to
nest them / align them / make arrays of them / have them hold pointers / ...?
We don't support that "yet". Worse: they support it but it's buggy.). Heavens
help you if your argument has (gasp) an initializer or one of the arguments is
a reference. Maybe things have changed in the last ~5 years, but I doubt it.

If Julia's intimate connection with LLVM makes it practical to implement a
better FFI or hybridize FFI + wrapper code when necessary, it will have a very
valuable advantage over python for purposes of scientific computing. Maybe
even enough to displace it in the long run.

EDIT: By "hybridize" I mean that the ability to embed asm,C,C++ in Julia with
the same ease that you can embed asm in C/C++ would be a KILLER feature.

~~~
digikata
> I've never met a FFI I didn't come to loathe

I've felt that pain. With so many new programming languages popping up, I've
been wondering if the next killer programming improvement isn't strictly a
programming language at all, but rather something that rethinks the linker,
manages execution, and facilitates interfaces between larger blocks of code
(maybe in multiple languages).

~~~
jjoonathan
I've heard many very smart people (professors, leaders of large HPC efforts,
"language geeks") express the same sentiment over the years. Unfortunately,
it's a btch of a problem, as attested to by the veritable graveyard of half-
baked solutions out there. Apple's "Bridge Support" is the closest thing I've
seen to success (haven't worked with MS's CIL) and it leaves much to be
desired.

I'm not sure there _is_ any way around the impedance mismatches between
languages. They're all slightly different for a reason. Perhaps clean C APIs
are the best we can hope for.

~~~
digikata
I keep hoping that some accessibility upgrade comes to the linker akin to how
LLVM made compiler infrastructure more accessible, might make FFI bridging
more automated. For example, if GDB can access and take apart C structs an
automated way, why is FFI coding always seem to have programmers do a lot of
mechanical interfacing work.

Not that all the other JVM, CIL, etc aren't approaches that yield some
improvements, but something that upgrades capability or accessibility at the
level of the ABI linkage level is going to be a wider impact.

------
astrieanna
The author and I like Julia for nearly opposite reasons. (I write Julia for
the language geek reasons. The power of homoiconicity is amazing for writing
static analysis in the language you're analyzing.) It's really cool that Julia
can appeal to people with nearly opposing priorities tho. :)

I'm looking forward to giving the workshop at UChicago. It'll be my third time
presenting an Intro to Julia workshop.

~~~
tomrod
Will you be webcasting?

~~~
astrieanna
No, unfortunately not. We are hoping to record it, tho.

~~~
degenerate
Would love to see it put online :>

------
avodonosov
The reason to bet on Julia is disassembling a function? This is a standard
feature in Common Lisp (ANSI standardized in 1994)

    
    
      CL-USER> (defun f(x) (* x x))
      F
      CL-USER> (disassemble 'f)
      L0
               (leaq (@ (:^ L0) (% rip)) (% fn))       ;     [0]
               (cmpl ($ 8) (% nargs))                  ;     [7]
               (jne L33)                               ;    [10]
               (pushq (% rbp))                         ;    [12]
               (movq (% rsp) (% rbp))                  ;    [13]
               (pushq (% arg_z))                       ;    [16]
               (movq (% arg_z) (% arg_y))              ;    [17]
               (leaveq)                                ;    [20]
               (jmpq (@ .SPBUILTIN-TIMES))             ;    [21]
      L33
               (uuo-error-wrong-number-of-args)        ;    [33]

~~~
kisielk
This is also possible to a degree in Python, though you only get the bytecode:

    
    
        >>> def f(x):
        ...     return x * x
        ...
        >>> import dis
        >>> print dis.dis(f)
          2           0 LOAD_FAST                0 (x)
                      3 LOAD_FAST                0 (x)
                      6 BINARY_MULTIPLY
                      7 RETURN_VALUE

~~~
sitkack
And the bytecode is just calling polymorphic methods. All the real work is
done in the object implementations of type(x). I was very bummed years ago to
realize how shallow the bytecode representation in Python is. There is no sub-
terpreter, just C.

------
elteto
To each its own I guess, but I wanted to say that I don't see "safety, type
systems and homoiconicity" and other theoretical "geek" stuff as orthogonal to
a programming language's ease of use, productivity and expressiveness. If
anything they complement each other. The theory behind it provides a
consistent framework so that you minimize the mixing of different paradigms
and you can express ideas in a more consistent way. I very much doubt that a
language where you just throw stuff in would be easy to use. If Julia is a
great language is precisely _because_ of all the thought that went into it,
the ideas behind it didn't just materialize in someone's brain.

~~~
ahuth
I don't think his point is that "safety, type systems and homoiconicity" don't
matter. His point is that those things don't interest him as much as getting
things done do.

Those things may help him get things done, but they're for other people to
worry about while he works on his own stuff.

Also, am I the only one that doesn't know what 'orthogonal' means? I assume
from the context it means that these things aren't mutually exclusive.

Not really sure about 'homoiconicity,' either.

~~~
benaiah
Orthogonal literally means "perpendiular" \- it refers to two things that
aren't related at all. So, non-mutually-exclusive is part of it, but not the
whole picture.

FYI

------
shele
"Julia was not designed by language geeks — it came from math, science, and
engineering MIT students"

This statement is built on a false dichotomy. And it is not really true for
Julia, take the type system for example, sophisticated AND unintrusive.

~~~
exDM69
> "Julia was not designed by language geeks — it came from math, science, and
> engineering MIT students"

This makes me a bit cautious about the language. Scientific computing people
are often very smart but they are not programmers or computer scientists and
may do funny things that a computer scientist would not. Like one based
indexing of arrays in Julia. This is not a big deal but I'm a bit wary that
there may be some nasty surprises for a language geek computer scientist like
me :)

Another example is the byte addressing of UTF-8 strings, which may give an
error if you try to index strings in the middle of a UTF-8 sequence [1]. s =
"\u2200 x \u2203 y"; s[2] is an error, instead of returning the second
character of the string. I find this a little awkward.

There's a flip side to this too, if you're dealing with scientific computing
there seems to be a wide variety of scientific computing libraries available
in Julia [2].

Overall I find this language very interesting and it is on my shortlist of new
languages to take a look at when time permits.

[1]
[http://docs.julialang.org/en/latest/manual/strings/#unicode-...](http://docs.julialang.org/en/latest/manual/strings/#unicode-
and-utf-8) [2]
[http://docs.julialang.org/en/release-0.2/packages/packagelis...](http://docs.julialang.org/en/release-0.2/packages/packagelist/)

~~~
simonster
> Another example is the byte addressing of UTF-8 strings, which may give an
> error if you try to index strings in the middle of a UTF-8 sequence [1]. s =
> "\u2200 x \u2203 y"; s[2] is an error, instead of returning the second
> character of the string. I find this a little awkward.

Yes, it's a little awkward, but to understand why this tradeoff was made,
think about how you'd get the nth character in a UTF-8 string. There is a
tradeoff between intuitive O(n) string indexing by characters and O(1) string
indexing by bytes.

The way out that some programming languages have chosen is to store your
strings as UTF-16, and use O(1) indexing by two-byte sequence. That's not a
great solution, because 1) it takes twice as much memory to store an ASCII
string and 2) if someone gives you a string that contains a Unicode character
that can't be expressed in UCS-2, like 🐣, your code will either be unable to
handle it at all or do the wrong thing, and you are unlikely to know that
until it happens.

The other way out is to store all of your strings as UTF-32/UCS-4. I'm not
sure any programming language does this, because using 4x as much memory for
ASCII strings and making string manipulation significantly slower as a result
(particularly for medium-sized strings that would have fit in L1 cache as
UTF-8 but can't as UCS-4) is not really a great design decision.

Instead of O(n) string indexing by characters, Julia has fast string indexing
by bytes with chr2ind and nextind functions to get byte indexes by character
index, and iterating over strings gives 4-byte characters. Is this the
appropriate tradeoff? That depends on your taste. But I don't think that
additional computer science knowledge would have made this problem any easier.

~~~
StefanKarpinski
It's also essentially the same approach that has been taken by Go and Rust, so
we're in pretty decent company. Rob Pike and Ken Thompson _might_ know a
little bit about UTF-8 ;-)

------
cjfont
> The problem with most programming languages is they're designed by language
> geeks, who tend to worry about things that I don't much care for. Safety,
> type systems, homoiconicity, and so forth. I'm sure these things are great,
> but when I'm messing around with a new project for fun, my two concerns are
> 1) making it work and 2) making it fast. For me, code is like a car. It's a
> means to an end. The "expressiveness" of a piece of code is about as
> important to me as the "expressiveness" of a catalytic converter.

You want a fast car, but don't care much for having an aerodynamic design,
hmmm..

EDIT: In retrospect I now think he means he wants to be able to _create_ the
project fast, and this is not about performance.

~~~
tptacek
This is a confusing rebuttal, because cars have an aerodynamic design
primarily for performance reasons, and Evan is very clear in this article that
his _primary concern_ is performance. I think you've misread him.

~~~
cjfont
And yet he doesn't care about type systems, which are largely implemented to
help with optimization, you see.

~~~
tych0
Really? My impression is that it's largely correctness.

~~~
Skywing
But that allows for smarter optimizations.

~~~
tych0
Of course it does, and I never said it didn't. I just said that my impression
is that the primary motivation of language people is correctness. However, I
have published several in the area of software verification, so perhaps I am
biased.

------
haberman
Can Julia be a competitor to R? I love R in concept (interactive environment
for statistical analysis) but the language just drives me crazy in its
multitude of types and the loosey-goosey ways it converts between them.

A friend of mine is really proficient with R; when I walked him through some
of the R patterns that are very confusing/irregular to me, he sort of laughed:
he could see what I was saying but he said "with R you can't worry about
things too much, you kind of just have to just go with it."

If Julia can serve some of the same use cases but in a better-designed way,
sign me up!

~~~
sampo
Already in 2008 one of the R creators, Ross Ikaha, talked about how R is
fundamentally slow and has inefficient memory use. And that a "next gen R"
would be needed, and he was considering Common Lisp for the underlying
language on compiler. See the "Back to the Future: Lisp as a Base for a
Statistical Computing System".

[https://www.stat.auckland.ac.nz/~ihaka/?Papers_and_Talks](https://www.stat.auckland.ac.nz/~ihaka/?Papers_and_Talks)

But now apparently Julia also fulfills Ihaka's requirements for the basis on
the "new R" system, so I wonder is the need-for-speed part of the R community
is considering a switch to Julia, instead of building a "new R" from scratch?

~~~
otoburb
Lobbying Ross Ikaha to endorse Julia as the new R would hopefully bring more
people over to the language. Instead of just the Matlab folks you would also
renew interest with the slightly larger audience using R today.

------
Blahah
Just yesterday I decided to start seriously developing in Julia. High-level
languages are a bottleneck for computational biology. We need to be able to
write things fast, and have them run fast. So far no language really does
this. But Julia looks like the one.

I'm going to put together a BioJulia team is anyone is interested in playing.

~~~
ikryukov
I suppose I need to explain my position on the involvement of Julia in
bioinformatics a little bit more than just a short "I want to play" statement.
What follows is a bit of a rant that attempts to explain why things are bad
and that we need to work to make them better.

I have been in the field of computational biology for (practically) 3 years.
In this time, I have seen my fair share of bad tools and silly approaches to
very basic problems. A lot of the computer science folks may not realize it,
but there is a lot of trouble of basic software engineering sort in
computational biology. There is a lot of old, unmaintaned code, messy projects
implemented in multiple languages, and (of course) bugs. It does not appear
that anybody checks or maintains their code after publication - the projects
often die after they appear in a journal once.

There is a number of reasons that the situation is the way it is. One of the
sadly obvious ones is that the academics do not have the time or desire to
maintain their code. Some of the project would require full-time coders to be
maintained - and that is indeed the case for some of the bigger and more
popular tools. This results in the fact that some projects never take off or
live up to their potential - for the simple lack of time. The wasted effort
means that a lot of work is being re-done and science in general stagnates
because of that. There is no easy solution to this problem (other than
centralizing the efforts somehow - but that is the question of community, not
tools).

The issues that can be made better are the following (and I will start with
the most obvious ones first):

1) We need a language that is both easy to write in and is fast enough for
production. Too many times there exist projects that are written in multiple
languages. I have myself partaken in a few of those. The high level code is
usually written in python or perl (I shiver of the thought), while the heavier
numerical things are done in C or C++. This creates a rather large divide in
terms of who does what - quite often folks only know a single high level
language - so the numerical implementation stays opaque with only a single
person knowing how it works. This means that projects of that sort quickly
become unmaintainable. There is also a lot of glue code written - and God help
you if you need to understand how perl-guts work. If there was a single sane
implementation for both high level and numerical stuff, it will solve a lot of
those problems.

2) We need a fast language. Building on the previous argument - the reason for
splitting is quite often performance. This means that we use a single language
for both layers - and we get the "Node.js" effect (I'm not sure who to
reference this phrase to) - both front- and back-end stuff comes together.
This also means that you are not penalized for using complicated data
structures in your numeric code - so one level of separation falls away
automatically.

3) We need a language with a large number of capabilities. Julia community is
aiming to replicate a lot of the functionality of R. That means that it is
already possible to use Julia for, say, an undergraduate statistics course.
There is absolutely no reason (other than the historical, of course) why R is
used by the statisticians. It was written by statisticians for statisticians -
and has a lot of nice features. However, that means that a lot of the
efficiency considerations have been missed. R does a whole lot of data copying
- which is ridiculous for large data sets. For the growing crop of
statisticians it will barely make a difference which language is used - I
would go as far as to say that a lot of undergrads will not even notice the
difference, but those who will, will thank us later.

4) We need a functional language. Much rather, we need a multi-paradigm
language that has a strong functional basis. The advantages of the functional
approach are too many to name here - and I am afraid this is already becoming
incomrehensive. A lot of formal math and stats is really easily translatable
into functional mindset - and that is a great boon if you are trying to
implement an algorithm out of a math paper. Also, Julia does not restrict you
to think in a particular way - it is very adatable to your thinking patterns.

These are just a few reasons that I would try give to support a case for a new
language in the scientific community.

~~~
ikryukov
Just as a conclusion, I would like to point those interested to the current
available library implementations of the bio- related stuff (i might be
missing other stuff out there): 1) BIO-seq:
[https://github.com/diegozea/BioSeq.jl](https://github.com/diegozea/BioSeq.jl)
2) Fasta-IO:
[https://github.com/carlobaldassi/FastaIO.jl](https://github.com/carlobaldassi/FastaIO.jl)
3) Phylogenetics:
[https://github.com/Ward9250/Phylogenetics.jl](https://github.com/Ward9250/Phylogenetics.jl)

------
farslan
We have a Julia and iJulia app on [https://koding.com](https://koding.com).
It's going to be used by Harvard & MIT students soon. It's public and everyone
can try it by simple login to Koding. The best part is you can easily try it
online, without installing anything. Here is an screenshot of how it's look
like (iJulia and Julia inside Terminal):

[http://d.pr/i/MsZt](http://d.pr/i/MsZt)

The source of this app can be found here:

[https://github.com/gokmen/julia.kdapp](https://github.com/gokmen/julia.kdapp)

I'm happy to answer any questions :)

~~~
axman6
I find the fact that I can't even find out what koding.com is when using IE 9
pretty obnoxious. Love it or not, many people are forced to use older
browsers. Sending them to
[https://koding.com/unsupported.html](https://koding.com/unsupported.html)
without any explanation at all a great way to make people not want to bother
finding out what you're offering.

~~~
whatevsbro
But you do know and understand why they're not interested in supporting IE,
right? And you'd feel the same way in their shoes, yes?

------
sdegutis
This sounds like premature-optimization to me.

Maybe it's just me, but in the apps I write in dynamic languages, the
bottleneck is rarely in the language. It's usually in some IO.

EDIT: some sentence in the article gave me the impression he was using this
for non-math-heavy stuff which is why I said this

~~~
thinkpad20
Julia's primary purpose is as a scientific language, which means lots of
number-crunching on large data sets, complex computations, etc. IO is unlikely
to be the bottleneck in these situations.

~~~
mjn
I'm not sure I agree with the second sentence. Any kind of crunching on large
data sets has I/O bottlenecks as one of its main issues. When you're crunching
on a terabyte of data, pretty much the most important thing is your precise
strategy for handling that terabyte of data. I'll agree the asm can be
interesting still there in some cases, though, if you think of memory-
bandwidth-and-latency issues as part of I/O. There are definitely scientific
simulations where compute throughput is the only real issue, but I think of
them as a bit different kind of setting than big-data processing (stuff like
solving complex sets of equations, which has low I/O but high computational
requirements).

~~~
thinkpad20
Yeah, I shouldn't have conflated big-data issues with numerical computing.
Good catch.

Mostly I was responding to the idea that there is a relationship between
dynamic languages and IO bottlenecks. This is certainly often the case in
things like web development, where dynamic languages dominate, but under the
hood, Julia has relatively little in common with Python/Ruby/JS/PHP/etc, in
terms of how it's implemented or, especially, what it's intended to do.

------
mateuszb
It's been done 55 years ago:
[http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec...](http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_disassemble.html)

~~~
Homunculiheaded
I'm pretty confident that in 55 more years we'll be at the point where the
state of the art in programming language will be to simply rediscover Common
Lisp.

------
tieTYT
> my two concerns are 1) making it work and 2) making it fast.

What about maintainability? "Code as if the next guy to maintain your code is
a homicidal maniac who knows where you live." -Kathy Sierra and Bert Bates

In my experience, making something work and making it (relatively) faster is
easy. Making it easy to read is hard.

~~~
untog
Seems like that's exactly what he doesn't care about. If you're prototyping or
writing a lot of one off operations (for data analysis, maybe) then
maintainability is less important.

~~~
tieTYT
IME, you only know that with hindsight. I have made one off programs I never
needed to look at again. I've also made what I _thought_ were one off programs
that I needed to maintain for a while.

Even in a prototype, you may need to rework a particular piece of code
multiple times before it works correctly. Even with a prototype, you may need
to use it as a reference for your official version. Even with a prototype, you
may end up having to use that as the official version (usually not by my
choice).

Also, caring about speed 2nd is shocking to me (but maybe I just come from a
different world). What if it isn't fast enough on your first attempt? Won't
you wish your code was maintainable so you could change it to be faster?

~~~
lightcatcher
> What if it isn't fast enough on your first attempt? Won't you wish your code
> was maintainable so you could change it to be faster?

From my experience, this isn't the case at all. A lot of the time my first
attempt is in Python. The first attempt is really more of a prototype or a
proof of concept. If the code works and I want to productize it, the code
needs to be sped up. I have (at least) 2 choices: (1) make the Python code as
fast as possible or (2) rewrite the whole thing in C/CUDA. If I take option 1,
performance gains will be marginal and I still probably won't be happy with
the performance of the software. Option 2 might take a bit longer, but at
least I'll get something performant out. As I'm just throwing out and
rewriting the first attempt, I don't actually care at all if it was
maintainable code. I don't even care if the ideas in it were well
explained/commented, because they're all my ideas and they're still fresh in
my mind and I'm just going to rewrite the code and then document/clean up the
fast version.

The appeal of Julia is that I no longer have to do this rewrite to make my
code fast. Furthermore, if I don't have to do this rewrite, it is actually in
my interest to make my first version of the code be maintainable and well
documented.

~~~
tieTYT
Fair enough. But you ignored/changed the foundation my reply was built on. I'm
replying to TFA saying "speed is second" and maintainability is... not
considered. You're talking about "correctness being first" and
speed/maintainability being not considered.

------
thinkpad20
I've tried Julia out a few times and been very impressed. From what I've seen
it really does a great job of bridging the gap between easy-to-use and high-
performance. It kind of seems like D in that way. I can definitely see lots of
situations where a language like this is desirable.

I'm in Chicago (and a U of C grad!). I might come to the meetup if I can.

~~~
loganfrederick
I'm also in Chicago and probably going to the meetup. I haven't tried Julia,
but I'd be interested in trying it with the help of experts.

------
tesmar2
> but it's poised to do for technical computing what Node.js is doing for web
> development

I stopped right there. Node.js has only a few great use cases where it shines
and in the real world, the vast majority of shops have not switched to using
it.

~~~
Mikeb85
> Node.js has only a few great use cases where it shines and in the real
> world, the vast majority of shops have not switched to using it.

Of course not. 'Switching' is usually more pain than it's worth, especially if
your previous solution works. New start-ups are likely the ones who will be
using it, just as Rails took off in the start-up world.

Likewise, R and Python are going to continue to be in use in existing
projects, and Julia is the potential future...

~~~
tesmar2
In my experience, most people are turned off by using Javascript on the
backend of web-development. Your experience may be different, but I just don't
think the analogy made in the original article is a very good one.

~~~
Mikeb85
They may be turned off, but in my experience setting up a Nodejs backed site
is incredibly easy with the way the frameworks, libraries, and everything are
written. That alone will appeal to a lot of people. Front-end only people
could easily put together a Nodejs backed up in no time at all.

Or you could use something like Coffee-script from front-to back. It's a very
easy eco-system to get into.

------
RivieraKid
I've used Julia for couple of projects and it's amazing, I seriously believe
that Julia is better - in several ways - than _all_ of the widely used dynamic
languages like Python, Ruby, Clojure, Octave or Lua. It's a brilliantly
designed language. There are so many things to like about this language.

------
sdegutis
Wait a minute! Can you embed Julia into a C program like Lua? Can it interface
with complex C types cleanly?? This might be the scripting language I'v been
looking for in my side project!

~~~
sdegutis
Wow. Okay, yes. It can be embedded[1]. It can call C code[2].

Julia may have just saved my project (which was dying because it needed a good
scripting language that was fast)!

[1]:
[http://docs.julialang.org/en/latest/manual/embedding/](http://docs.julialang.org/en/latest/manual/embedding/)

[2]: [http://docs.julialang.org/en/latest/manual/calling-c-and-
for...](http://docs.julialang.org/en/latest/manual/calling-c-and-fortran-
code/)

~~~
3JPLW
And embedding (and its documentation) will likely get much better very soon.

[https://github.com/JuliaLang/julia/pull/4997](https://github.com/JuliaLang/julia/pull/4997)

~~~
sdegutis
One big pain point so far is that it won't be easy to actually embed Julia
into my app. So users of my app will have to install Julia (probably via
homebrew) before they can script the app with it.

------
foundart
I see the Julia home page lists multiple dispatch as one of its benefits.
Since my only real exposure to multiple dispatch was when I inherited some
CLOS code where it was used to create a nightmare of spaghetti, I'm wondering
if any Julia fans here would care to elaborate on how they've used multiple
dispatch for Good™ instead of Evil™

~~~
astrieanna
Multiple dispatch lets you make math operators work like they do in path. That
means that you can use `+` the same way on ints, floats, matrices, and your
own self-defined numeric type. If `x` is a variable of your new numeric type,
OO languages make making `x + 5` work easy, but `5 + x` super hard. Multiple
dispatch makes both cases (equally) easy. This was, as I understand it, the
major reason that Julia uses multiple dispatch.

Multiple dispatch can make interfaces simpler: you can easily offer several
"versions" of a function by changing which arguments they take, and you can
define those functions where it makes sense, even if those places are spread
across multiple modules or packages. Julia provides great tools (functions)
that make methods discoverable, help you understand which method you're
calling, and help you find the definition of methods.

Looking at some Julia code (the base library or major packages) might give you
a better idea of how Julia uses multiple dispatch.

~~~
foundart
Totally makes sense. Thanks for the info. Will also dig around in the code.

------
evanspa
When I read the opening paragraph, I immediately thought of the author as a
Blub programmer [1].

"The problem with most programming languages is they're designed by language
geeks, who tend to worry about things that I don't much care for. Safety, type
systems, homoiconicity, and so forth. I'm sure these things are great..."

Yes, those things are great. They ultimately aid in helping the programmer
tackle the inevitable complexity that arises when building systems in a
maintainable way.

[1][http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

~~~
john_b
You're assuming the author wants to use Julia to build complex systems. Much
of scientific computing has no need to do so, but is more concerned with
discovering new knowledge and testing new ideas. Once the knowledge is gained,
products may be built around that knowledge or new inquirires may be launched
from it, but scientific computing usually uses programming languages as
research tools rather than development tools.

~~~
Fomite
This. The amount of code I write that never gets touched again after a paper
goes to press is staggering.

------
smortaz
mini ASK HN: would there be any interest in supporting Julia in Visual Studio?
(as a free/oss plugin).

i lead the Python Tools for Visual Studio project at msft and would be curious
if there is interest.

as a side note, if you do you use Python & require Python/C++ debugging, PTVS
now supports it:
[http://www.youtube.com/watch?v=wvJaKQ94lBY#t=10](http://www.youtube.com/watch?v=wvJaKQ94lBY#t=10)

~~~
KenoFischer
Are you using the IPython protocol for communication with python? If so,
extending it to julia should be fairly straight forward.

~~~
smortaz
we are for the integrated IPython REPL. but my question was more in terms of
intellisense, debugging, profiling, mixed julia/C++ debugging, etc. ie, a
fully integrated experience in VS.

~~~
iamed2
The fully integrated experience you mention would do a lot for the Julia
community in terms of gaining users tied to the GUI elements of MATLAB and VS
for other languages. Integrated debugging and inspection in particular is a
long-requested feature that has yet to see much attention.

Integrating with Pkg as Julia Studio does would be another important feature,
as well as providing some sort of integrated plotting/graphics widget (a
backend canvas along with plot navigation and image export, ideally supporting
more than one of Julia's plotting backends).

I would certainly contribute to an alpha- or beta-testing effort :)

------
eonil
Does Julia have AOT compiler which produces a binary which can be linked to a
C program? I am asking this because I have to consider availability on iOS -
which is a platform prohibits JIT.

~~~
kazagistar
Alas, last time I checked this was still on the todo list. With sufficient
annotations and type inference, there is no reason this would not be possible,
but they way it sounded it would take rewriting or creating large chunks of
core code and algorithms.

------
tenfingers
There's a lot to love in Julia, but my biggest nitpick is the 1-based array
index. I can see where it comes from, but it's not something I can praise. I
use R on a daily basis, where the aim is mostly interactive analysis, and
still I cannot see any reason to use 1-based indexes. For a language that is
instead mostly oriented to programming, I would have not went for the
"familiarity" argument.

~~~
thinkpad20
I'm guessing whoever was responsible for that decision was either a hardcore
FORTRAN or MATLAB user, since both of those have 1-based indices. Or by a
similar token, they could have chosen that because they expect that many of
their users might be coming from either of those languages. I guess you'd get
used to it, but I agree it's a big drawback.

------
weatherlight
I love Julia, Coming from the Ruby world it was very easy to get into.

It was easy to see how useful and expressive the language was by just doing a
few Project Eulers.

------
zem
the interesting thing is that what excites me about julia is that it is
clearly a scientific computing language designed by people who _are_ language
geeks. the feature set seems very clean and well-thought-out to me.

------
wirrbel
I don't really see the need for the author to make himself into a "cowboy"
coder and point out how they ignore all those valuable insights and
enlightenments of programmers.

Julia is a kind-of-fine language that is designed to appeal Matlab users first
of all by its syntactical looks. Just like Javascript was designed to appeal
to C and Java users by imitating their look.

Under the hood, Julia is quite a smart development, not only in terms of code
generation, but also in terms of datatypes and object models.

Multiple dispatch is something that more or less only Lisps typically offer
natively (and Dylan). When working with types (especially in dynamically
strongly typed languages) this is often something what I am missing in other
languages. Consider Python:

    
    
        if isinstance(x, Y):
            ...
        elif isinstance(x, Z):
            ...
    

This feature alone shows that the authors of Julia are rather the thoughtful
language-loving authors.

So I would like to leave the small scope of the article but look at the
greater picture: Julia and its competitors. There are actually quite a few on
the market. A few domain-specific numerical libraries exist for C/C++/Fortran
for scientific purposes (ROOT at Cern, etc.). They are more or less falling
out of fashion. For a long time, Matlab has been dominant in some faculties
for evaluation and working with data, process signals and images. It is not by
accident that Matlab was created as a convenient Wrapper to Fortran libraries
at the time. From a software developer's perspective, Matlab is for Cowboys.

Next to its high price (and the vendor lock in forced upon college and
university students who are trained for matlab when there exist suitable open
source alternatives), the most appalling thing about Matlab is its poor
performance as a programming language. While its easy to write small scripts,
solve linear algebra problems and plot a few things, I have hardly seen well
organized Matlab code and I just think that it is impossible. While Matlab
licenses cost heaps of money, support is not good and upon a version change
you have to spend considerable amounts of work getting around API changes.

The Matlab clones available (Octave) are generally unimpressive. I think this
has to do with the big effort of copying Matlab and the need to develop the
whole tool stack (parser, interpreter, libraries). Contributors are hard to
find because octave hardly offers any benefit over the original, like ReactOS
with Windows, Octave can only react. I still value the effort of the octave
folks, they have done some great work!

Scientific Python has chosen a slightly different path. Taking the fairly
uncontroversial programming language Python, the authors created an
infrastructure of thematically separated modules. While eliminating the need
to design and implement an own programming language, a lot of work could be
spent on building useful libraries. Also, existing libraries were reusable
(databases, XML, etc.) and Python is a really convenient programming languages
for both Newbies and professional software developers. So with this pragmatic
approach, the contributers have created one of the best environments for
scientific software development and would be my suggestion for anyone at the
moment who just wants to use one system.

What still amazes me: While working in an ipython notebook
([http://ipython.org/notebook.html](http://ipython.org/notebook.html)) on some
numerical calculations, I can just pull up Sympy
([http://sympy.org](http://sympy.org)) and perform some symbolic computations
(Fourier transforming some function analytically or taking the derivative of
some other, etc.).

Oh, and have I told you about how Scipy can replace R for really cool
statistical analyses?

The part where Julia kicks in now is the point that Matlab has a lot of market
ground, especially with engineers who are not extraordinarily passionate about
programing. For some people the burden of learning another syntax is just too
big, they are not full time programmers but spend their time more with
acquiring data and using the results. I really hope that some of them who are
not willing to switch to scientific python can agree on switching to Julia.

Full Disclosure: I have occasionally been forced to work with Matlab (so I do
have some experience with it without being an expert) and it was not fun. This
is one of the reasons I would like all Scientists to have the chance of
choosing a good environment that is suitable for them. If its Matlab for some,
so be it ;-) I have never looked back.

~~~
xixi77
_What still amazes me: While working in an ipython notebook
([http://ipython.org/notebook.html](http://ipython.org/notebook.html)) on some
numerical calculations, I can just pull up Sympy
([http://sympy.org](http://sympy.org)) and perform some symbolic computations
(Fourier transforming some function analytically or taking the derivative of
some other, etc.)._

You can certainly do it with Matlab (provided you have purchased the symbolic
toolbox of course).

 _Oh, and have I told you about how Scipy can replace R for really cool
statistical analyses?_

Sure, it can for some things, but why?

My thing with Python is that it kinda loses to Matlab for non-statistical work
(except perhaps for select fields, like network analysis or language
processing), and to R/SAS/Stata (depending on type of job and personal
preference) for statistical stuff. Of course all of these (other than R) are
proprietary and not cheap, but most universities have all of them anyway, and
businesses just buy what they need.

btw: did you first learn Matlab, or Python? In my experience, there is a
tendency for people who start with Matlab to dislike Python, and for people
who start with Python to dislike Matlab :) Probably has something to do with
some basic things being just so slightly different, and therefore bothersome.

Also, the Matlab IDE these days is actually quite decent -- does Python have
something similar?

~~~
wirrbel
Sure enough there are parts of matlab where matlab is without serious
competitors. I think however that a majority of needs is available for Python,
although I know that I do not represent everyone's needs.

Quick google search yielded:
[http://networkx.github.io/](http://networkx.github.io/) do not know how it
compares though.

I switched to Sci.Python at the point where I had difficulty treating time
series data with Matlab. I know there is a toolboxy-thingy from mathworks but
it either was not available or I did not find the documentation. Anyway, I
quickly got started with Pandas. I had prior knowledge of Python and other
mainstream programming languages before.

Spyder is a Matlab-ish IDE with a variable explorer, etc. Some like the
Ipython Notebook which I think is great for demonstrations and teaching, but
eventually does not scale when projects grow bigger.

~~~
xixi77
Yeah, networkx is pretty good -- I actually meant that network analysis and
text processing are the two areas where I'd be quite comfortable recommending
Python over Matlab.

For time series data, I'd personally pick R though, or perhaps SAS if it's
large enough -- at least if any statistical analysis is involved...

I need to check out Spyder.

~~~
wirrbel
R is a software that I still need to check out.

I think enthought offers commercial tooling and support and also a IDE
platform with tools for data story telling etc.. I usually use vim.

~~~
xixi77
R design is somewhat like perl in the sense that usually there are a lot of
ways of doing anything. This includes time series of course. That being said,
last time I did time series, I've used xts and was quite happy with it.

------
rubyn00bie
Not to be a an asshole, something I have to preface a lot on here... but, uhh,

"Safety, type systems, homoiconicity, and so forth. I'm sure these things are
great, but when I'm messing around with a new project for fun, my two concerns
are 1) making it work and 2) making it fast."

Uhhh... Call me crazy, but wouldn't the "so forth" be what you care about if
#2 is that important to you?

------
weichi
How good is the interactive plotting experience?

~~~
astrieanna
I haven't had the smoothest experiences getting plotting in general to work
(it's getting progressively better). The plotting in IJulia using PyPlot
(matplotlib wrapper) has been good for me.

The Julia plotting packages are Winston, Gadfly, and Gaston. You can find
detailed discussions of which one to use on the julia-users mailing list.

~~~
weichi
Thank you. I can appreciate that it's difficult to implement good interactive
plotting, especially across platforms. It's also very very important!

------
Malarkey73
This is odd as a much better post on Julia v R v MATLAB v Python etc has got
little attention: [http://slendermeans.org/language-
wars.html](http://slendermeans.org/language-wars.html)

------
rrggrr
I'm betting on Scratch.

The benefits of automation are mostly denied to me because I haven't the time
to learn Julia or properly use the Python skills I already possess. I do
however have the time to link and configure objects ala Scratch and Apple's
Automator, or the first generation of what was once Allaire's Cold Fusion. Its
not just me, either. The demand for automation tools is pervasive in business
and education, but the time and innate skills needed to program effectively
belong to a subset of the needy. Bring me a language that is truly a means to
an end and take my money.

------
georgewfraser
Is there reason to believe Julia is actually fast outside of microbenchmarks?
Their strategy of aggressive specialization will always look good in
microbenchmarks, where there's only one code path, but could blow up in a
large codebase where you actually have to dispatch across multiple options.
I've never seen a Julia benchmark on a big piece of code.

~~~
sixbrx
I've had some problems with Julia performance for a finite element method
implementation
([https://github.com/scharris/WGFEA](https://github.com/scharris/WGFEA)),
mostly I _believe_ because of (1) garbage generated in loops causing big
slowdowns and (2) slow calls of function closures. Functions defined at the
top-level which don't close over environment values are fast, closures however
are quite slow, which is really painful for situations where closures are so
useful, e.g. to pass as integrands to integration functions.

There is an github-issue about the closure slowdown, but I don't have it
handy. Both can be worked around, by writing in a lower level style, e.g. by
using explicit loops acting on pre-allocated buffers, avoiding higher-order
functions, etc. The pre-allocated buffers can be a lurking hazard though (Rust
avoids the danger in the same strategy with its safe immutable "borrow" idea).
I felt like these workarounds were giving up too much of the advantages of a
high level approach for my own tastes.

I have converted to Rust to avoid the garbage collection for sure, and I'm
extremely pleased with the performance. It would be nice having a REPL though,
I do miss that. And I do intend to stay involved with Julia. I'm sure the
situation will improve.

Good high performance garbage collectors aren't easy (and they are easy to
take for granted after being on the JVM for a while) - that's probably the
biggest challenge for Julia as a high performance language, IMO.

------
blueblob
How does Julia interface with C? Is it easy to interface Julia with C because
all it does is compile the C with Clang/LLVM?

~~~
astrieanna
Julia does not compile the C code; it links against shared libraries. It helps
that Julia types can model C structs easily.

Manual entry on calling C:
[http://docs.julialang.org/en/latest/manual/calling-c-and-
for...](http://docs.julialang.org/en/latest/manual/calling-c-and-fortran-
code/)

Blog post on passing Juila callback functions to C code:
[http://julialang.org/blog/2013/05/callback/](http://julialang.org/blog/2013/05/callback/)

------
otikik
> the real benefit is being able to go from the first prototype all the way to
> balls-to-the-wall multi-core SIMD performance optimizations without ever
> leaving the Julia environment.

That sounds like someone who has not had to maintain any kind of software for
more than 2 days.

------
digitalzombie
I'm betting on Julia and Rust really. Julia for Scientific programming and
Rust for system.

------
DonGateley
I want to write audio VST plugins in this language! Somebody please make that
easy. :-)

------
mpchlets
Based on your comments of Cowboys, you have obviously never rode hard put up
wet.

------
DonGateley
Is there a Julia forum anywhere. Like with a hierarchy of topics and subtopics
and with hierarchical threads at the bottom level like HN? Optimally something
that remembers what you've read.

~~~
ihnorton
Not a forum exactly, but julia-users and julia-dev are hosted on Google Groups
which does threading and remembers what you've read. See the homepage for
signup (julialang.org)

~~~
DonGateley
Thanks. A good variety of things there but I'm hoping someone puts together a
phpBB (or similar) site such as Oculus Rift uses here:
[http://oculusrift.com/](http://oculusrift.com/)

Such an organized site where you could drill down to topics of interest
through broader categories would really be helpful. It would be best, of
course, if it was set up and accessed through julialang.org as something
official.

I don't know how to do that or I would. It isn't reputed to be very difficult
to set up a phpBB site and I'm sorta hoping some enthusiast who does know how
picks up on it.

------
allochthon
I like what I see so far at this page [1] and will watch closely to see
whether Julia catches on.

One thing -- can we call agree that dictionary literals begin and end with
'{}', that arrays are zero-indexed and that an index into a unicode string is
properly a character and not a byte? Or are we doomed to permute endlessly on
details such as these? I wish any new languages would set aside a large set of
tempting innovations and just go with the flow on the smaller points.

[1]
[http://learnxinyminutes.com/docs/julia/](http://learnxinyminutes.com/docs/julia/)

~~~
3JPLW
Well, in many ways, they are going with the flow. They're targeting
mathematicians, and R/Matlab users… all of whom use 1-indexed arrays. And,
really, the kinds of dictionaries you're used to _are_ constructed with {}
braces. The square braces hold more specifically-typed keys and objects. It's
a very clever analogy to their typed/untyped arrays. And wonderful for
performance.

    
    
        ["one"=> 1, "two"=> 2, "three"=> 3] # -> Dict{ASCIIString,Int64}
        {"one"=> 1, "two"=> 2, "three"=> 3} # -> Dict{Any,Any}

------
juleska
Ok, good to see, but, what i can do with it that i can't with another
language? -.-

~~~
carnaval
nothing.
[http://en.wikipedia.org/wiki/Turing_completeness](http://en.wikipedia.org/wiki/Turing_completeness)

------
bayesianhorse
I agree that Julia is great. But it's not there yet, either.

------
ggchappell
Figlet sighting. Font: big. :-)

------
enupten
All they're missing is a cool interaction mode like SLIME.

------
lafar6502
Looks strangely similar to Lua

~~~
zhemao
Well, most of the syntax he shows here is just calling functions. A lot of
dynamic languages have similar syntax for functions calls. But you're right
that Julia's syntax is superficially similar, with function definitions like

    
    
        function foo(bar, baz)
        end
    

and 1-based indexing of arrays (although Julia's use of that was to be similar
to MATLAB).

------
niix
No.

