
Why I am betting on Julia (2014) - sean_the_geek
http://www.evanmiller.org/why-im-betting-on-julia.html
======
mahmud

      CL-USER> (defun f (x) (* x x))
      
      F
      CL-USER> (f 2.0)
    
      4.0
      CL-USER> (disassemble 'f)
      
      ; disassembly for F
      ; Size: 37 bytes. Origin: #x1002B10BDC
      ; BDC:       498B4C2460       MOV RCX, [R12+96]               ; thread.binding-stack-pointer
                                                                    ; no-arg-parsing entry point
      ; BE1:       48894DF8         MOV [RBP-8], RCX
      ; BE5:       488BD3           MOV RDX, RBX
      ; BE8:       488BFB           MOV RDI, RBX
      ; BEB:       41BBB0020020     MOV R11D, 536871600             ; GENERIC-*
      ; BF1:       41FFD3           CALL R11
      ; BF4:       488B5DF0         MOV RBX, [RBP-16]
      ; BF8:       488BE5           MOV RSP, RBP
      ; BFB:       F8               CLC
      ; BFC:       5D               POP RBP
      ; BFD:       C3               RET
      ; BFE:       0F0B10           BREAK 16                        ; Invalid argument count trap
      NIL
      *

~~~
tomp
Julia does it an order of magnitude better, though.

A _generic_ `f` will probably be similar to the Common Lisp one. However, as
soon as you use `f` in a context where types are known (e.g. if you use
multimethods to overload a function that calls `f`), it will be _specialized_
and JIT-compiled for the specific type (int, float, matrix, ...), with no
extra work for the programmer.

~~~
lispm
In the 'Lisp World' JIT compiler are mostly not used. The main approaches are:

* program compilation, where the object system can declare parts as non-extensible

* a runtime compiler, which can compile methods

See for example for a recent attempt to statically compile methods and handing
the types to the optimizing compiler (which also uses type inference):

[https://github.com/guicho271828/inlined-generic-
function/](https://github.com/guicho271828/inlined-generic-function/)

~~~
baldfat
In the Lisp World, Racket has a great JIT which is optional.
[https://docs.racket-lang.org/guide/performance.html](https://docs.racket-
lang.org/guide/performance.html)

Racket is a beautiful thing.

~~~
lispm
Racket is Racket.

CLISP also can use a JIT - it uses GNU Lightning for runtime native code
generation
([https://www.gnu.org/software/lightning/](https://www.gnu.org/software/lightning/)).

Anyway the Racket JIT seems to be a bit limited:

> The JIT compiler works incrementally as functions are applied, but the JIT
> compiler makes only limited use of run-time information when compiling
> procedures, since the code for a given module body or lambda abstraction is
> compiled only once. The JIT’s granularity of compilation is a single
> procedure body, not counting the bodies of any lexically nested procedures.

------
phantom_oracle
When I read this, all I can think about is the enormous amount of man-hours
people have put in to make Python the go-to for Julias target market.

As the author says, the biggest drawback is libraries, and that is (1 of) the
big attraction(s) towards languages.

Nobody wants to have to switch between C, Python, Assembly, etc. to make their
code faster, but even fewer people want to write bindings to underlying C
code. This also goes exactly against what the author doesn't want to do, which
is to yak-shave around the language to get things working.

~~~
sdenton4
It's extremely common to prototype in a language like python or R to be able
to bang out a draft idea before diving into making it fast. If I'm not sure
how awesome something is going to be, there's no sense in wasting weeks
getting a C implementation working. And prototyping in a higher level language
often reveals a lot of the architectural complexity you'l have to deal with in
a lower level implementation. So I think this guy's use-case is more common
than you think.

Python addresses a good deal of the problem with Cython, which lets you
declare variables and compile to get ~90% of the speed gain you would get from
a pure C implementation. And then you can just link to a C implementation if
you still find you need to build one...

~~~
rm999
>It's extremely common to prototype in a language like python or R to be able
to bang out a draft idea before diving into making it fast.

I think what's far more common is prototyping something in Python or R, and
then realizing that 99% of its CPU time is already spent in wrapped C code.
And then you call it a day and move on to other things :)

This is why Julia hasn't taken off nearly as quickly as I initially expected -
Python/R/etc are highly optimized for their common use-cases.

~~~
ihnorton
> I think what's far more common is prototyping something in Python or R, and
> then realizing that 99% of its CPU time is already spent in wrapped C code.
> And then you call it a day and move on to other things.

Someone has to write those libraries.

> This is why Julia hasn't taken off nearly as quickly as I initially expected

Not sure what you were expecting, but consider:

\- the _most conservative_ userbase estimate I would believe is 20k users
(based on mailing list subscriptions, website stats, and download numbers).

\- sustained package ecosystem growth:
[http://pkg.julialang.org/pulse.html](http://pkg.julialang.org/pulse.html)

~~~
rm999
>Someone has to write those libraries

Yes, but the discussion is about the "extremely common" case of prototyping,
which definitely should not require library building, and usually should not
require veering much from established libraries.

>Not sure what you were expecting

The data community can coalesce around a tool extremely quickly, in the matter
of a year or two. Spark is about the same age as Julia, and has a thriving
ecosystem around it. In 2004 R was a fairly esoteric analysis tool, but
2008-2010 it was the de facto data science language. Python made similar
advancements in just a few years in the data science community.

Julia? I don't know a single person who uses it day-to-day, but I know a lot
of people who tried very hard (myself included). The critical mass simply is
not there: people aren't building packages because the users don't exist, and
they don't exist because the packages don't exist. Your chart shows a linear
growth in packages, which implies a constant amount of development work. _This
means it 's not a growing language_. This is what a growing language looks
like: [http://blog.revolutionanalytics.com/2010/01/r-package-
growth...](http://blog.revolutionanalytics.com/2010/01/r-package-growth.html)

~~~
tanlermin
I'm not sure you can make a linear projection.

This could be early exponential growth.

Or the constant growth may hit a tipping point as a critical mass of tools and
infrastructure is developed.

------
muktabh
This was in 2014. Here is a more recent perspective (from a different blogger
who used Julia in production) [https://blog.staffjoy.com/retro-on-the-julia-
programming-lan...](https://blog.staffjoy.com/retro-on-the-julia-programming-
language-7655121ea341)

~~~
sklogic
They tried to use Julia for things like networking instead of confining it
within purely numeric parts. No idea why would anyone use a DSL for doing some
"general purpose" stuff.

~~~
IshKebab
I've used Matlab quite a lot for "general purpose" stuff. Ok not networking,
but you'd be surprised how good it can be at non-numeric things.

Most of that was probably due to the slick GUI which nothing else comes close
to (I've tried them all; trust me), but that is a legitimate factor.

~~~
sklogic
Of course it _can_ be used for a general purpose stuff, but it _should not_ ,
because there are always much better tools that a specialised for those
domains. It's never a good idea to use a language for something it was not
designed for.

~~~
elcritch
Technically Julia is designed for general purpose computing. It just happens
to be _really_ good at numerical applications. The main thing holding it back
is lack of tooling, debugging, and somewhat largish changes in syntax still.
Having said that writing typed, expressive, and _performant_ DSL's in Julia is
easy if not even kinda fun.

------
tanlermin
I think it will all come down to web assembly. Why?

Python has blaze, numba, dynd and dask going for it. These all ameliorate (and
exceed Julia in some respects) many of the disadvantages of python (including
fast user defined types). Then there are the libraries that while some can be
used in Julia, you will never get full reliability, ease of use and
compatibility.

On the other hand, Julia has amazing metaprogramming and much cleaner
scientific syntax.

I think it will come down to whether Python can compile to fast LLVM regular
standard lib programs.

Once (if?) Julia can be run in the browser with web assembly (using ahead of
time compilation to produce small binaries), python has no chance if it
doesn't follow suit. Python has no advantage that can permanently match
Julia's potential ability to run on mobile, front end web, back end etc all
from one beautiful codebase.

What does HN think?

~~~
username223
> Julia's potential ability to run on mobile, front end web,...

Julia is designed for interactive, exploratory scientific programming, like
Matlab and R. I don't see any reason someone would want to do that on a phone
or in a web browser when it already runs natively on a PC. Then there's the
matter of Julia being designed to interface efficiently with optimized native
C/Fortran libraries.

~~~
KingMob
This. Scientific computing is not interested in running in web browsers.

As a former neuroscientist, I occasionally had connectivity analyses that
would take 3 _weeks_ to run. No way would I risk slowing it down with anything
unnecessary. A 25% slowdown for using VMs in the browser would mean
milliseconds for users and _days_ for me.

~~~
grayclhn
R's "shiny" is a counterpoint. Obviously something that takes a week to run
isn't going on the web. But a complex model and visualization that can be
_incrementally_ updated quickly and in real time? That would be cool.

~~~
elcritch
+1 for this! For large programs -- server side Julia, but having browser
native Julia via WebAssembly would make visualization and interactive analysis
for data science fantastic. Performance of running large GUI applications and
libraries would be much faster since WebAssembly could take advantage of the
huge amount of work done for optimizing JS by tiered interpretation/JIT'ing.

------
riscy
> Julia breaks down the second wall — the wall between your high-level code
> and native assembly [...] you can take a peek behind the curtain of any
> function into its LLVM Intermediate Representation as well as its generated
> assembly code — all within the REPL

While I agree with the author in "betting on Julia", I do not think inspecting
LLVM IR or assembly of individual functions in the REPL is as useful as a
feature as the author thinks, because it gives an inaccurate picture of what
the actual output will be.

Peeking at the code at the level of functions means a non-inlined version of
the function must be produced at the REPL, and anywhere else this function is
used in your actual code, it will probably be inlined (the author's example
certainly will) so it can be further optimized/eliminated by later passes.
Furthermore, for a non-trivial function's dump, fundamental optimizations that
increase code size (inlining, unrolling loops etc) would make the output
confusing to compare with the Julia equivalents.

Thus, I imagine a lower optimization level is used to produce readable REPL
dumps. For a performance minded person (the only type of person who would care
about ASM/LLVM dumps at a REPL) even this is not helpful.

~~~
3JPLW
Yes, when a function is inlined, the caller's context can dramatically affect
optimizations. And inspecting varargs functions can be tricky.

But beyond that, it generally displays exactly what gets executed. You can
verify this yourself by looking at functions with different `-O` or
`--inline=no` flags. And if you're interested how a function optimizes with
inlining under typical conditions, you can just inspect the outer function.

------
lmm
Language design is vital for a language that can evolve. If you build a
language for "cowboys" with the immediately-useful functionality that you can
see, but without the "language geeks" insisting on the underlying principles,
you end up with a language like perl - one that can dominate a particular use
case for a while, but will be virtually impossible to evolve, and ultimately
fall out of favour as it's overtaken by languages with firmer foundations.

That's why I'm betting on the strongly-typed functional tradition -
OCaml/Haskell/etc. These language already have the killer feature from this
article: they can be (almost) as expressive as Python and (almost) as
performant as (naive) C++. But they also have really solid design with a lot
of thought put into it that will let them evolve to meet the needs of the
future.

~~~
junke
Julia stands definitely on firm foundations, has a solid design and is
strongly-typed too.

~~~
lmm
Then why's it positioned as a numerical/datascience language rather than a
general-purpose language?

~~~
junke
Do you see a contradiction between having a good design and having a specific
purpose?

~~~
lmm
Yes. I think good programming language design is necessarily general, and the
best way to achieve that is with a language that's been validated in widely
varied domains. Certainly my experience is that specialized languages are
consistently worse than general-purpose ones.

~~~
junke
Julia is general-purpose, but there is a deliberate orientation towards
scientific computing. That's a partly non-technical choice about what is going
to be optimized in priority.

[https://stackoverflow.com/questions/17433435/what-makes-
juli...](https://stackoverflow.com/questions/17433435/what-makes-julia-
unsuitable-for-general-purpose-programming/17434967#17434967)

------
mynegation
It needs (2014) in the title if for nothing else than for the fact that a lot
could have changed since then, as Julia is pretty fast developing

~~~
dang
Added.

------
ProAm
> 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.

Im a sculptor, but all I make is coffee cups and ashtrays so I dont need to
worry about the minor details of things..... This is what abstraction gets us.

------
max_
The founders of julia are geniuses. The only problem the language is facing
is, marketing.

Juila is one of those great things that everyone should use, but are simply
bot promoted enough.

~~~
eggy
They're smart alright, but I think Julia has gotten a lot of play on other
channels besides the Matlab/tech world. The stopper is for me is use cases. I
play with ideas in Mathematica (notebook IDE for decades) because it has
everything at my fingertips, keep J programming language opened on my desktop
for quick prototypes (not just as a desk calculator), and if I need technical
libraries and speed, I just use C with the relative libraries (even though I
should learn Fortran :) ) I like Julia's syntax, and I think it will be more
general purpose as it matures, but it is already the wild mistress of the
Matlab playboy.

~~~
tanlermin
What other channels?

~~~
eggy
I meant that as a PL being pitched as a Matlab replacement, and for math and
science communities, it has had some highly visible, hyperbolic articles in
Wired ("Man Creates One Programming Language to Rule Them All"), Venture Beat,
Fast Company and other more broad startup and popular tech magazines. I like
the programming language J, and I think I can truly say it doesn't get a lot
of exposure outside of its niche along these lines, so I wouldn't say Julia
doesn't have good marketing; J has yet to be featured in Wired ;)

~~~
tanlermin
Gotcha!

------
rdtsc
2014\. Wonder if anything changed since then. How did author find using and
developing in Julia since then. Has their opinion changed?

~~~
mhd
[http://wizardmac.tumblr.com/post/104019606584/whats-wrong-
wi...](http://wizardmac.tumblr.com/post/104019606584/whats-wrong-with-
statistics-in-julia-a-reply)

The author writes that Julia still isn't ready to replace his current
development setup.

------
ones_and_zeros
Any thoughts on how it compares and will overcome the dominant enviromnent for
technical programming, matlab?

~~~
ninjin
What Julia really lacks at this moment is something along the lines of the
Matlab IDE. The community is aware of this though and there is something in
the works that even I, someone that lives happily with a ssh/tmux/vim set-up,
would deem as interesting.

Since we are on Hacker News, maybe I should also spread a rumour. MathWorks,
allegedly, in a recent settled lawsuit added a condition stating that the
other company was not to create any Julia bindings for its product. If this is
true, which I have many reasons to believe, it is a major recognition of how
at least MathWorks sees Julia as a real threat to the Matlab market share.

~~~
etrautmann
Certainly using Julia with Jupyter gets you much closer to having a reasonable
IDE, though you'll have to be comfortable with cell-mode debugging instead of
breakpoints and single stepping. I don't personally use it but I'm intrigued
and would love to switch away from Matlab if there were reasonable feature
parity or an alternate model that seemed reasonable for most basic tasks.

I'd really like to have a replacement for cell arrays and struct arrays, that
have some of the convenient features of those structures. I know you can get
this with lists of dictionaries in python, for example, but it's not the same.

~~~
ced
Have you tried dataframes? Whether in Julia or Python, they're a good
replacement for arrays-of-structs, though they need a lot of getting used to.

~~~
etrautmann
I've played around with them a little, but part of my issue is that our real-
time data acquisition (in a neurophysiology lab) uses matlab/simulink so I'd
need to create some middleware serializer to go from matlab data structures
into dataframes. Not too difficult but there's a lot of momentum behind the
matlab tooling unfortunately.

------
tombert
All of Evan Miller's programming reviews are good. I'm pretty sure it's been
posted on HN before, but I quite liked his take on Rust as well.

------
bleair
This review was really helpful to me when I was looking for more insight into
Julia. [http://danluu.com/julialang/](http://danluu.com/julialang/)

------
vfclists
Spoiler alert. Use Nim.

