
Giving up on Julia - ingve
http://zverovich.net/2016/05/13/giving-up-on-julia.html
======
KenoFischer
Happy to address these points:

    
    
      - Startup performance/memory usage
    

Yes, we are definitely very acutely aware of these. Julia is not currently
optimized for frequently run short scripts. That's the price on pays for
having to bring up the entire runtime system (initializing the compiler, RNG,
external libraries etc). The good news is that there will be a solution to
this soon, which is to statically compile your julia program. The area where
this really comes up for most people using is package load times. We're very
actively working on making that faster.

    
    
      - Syntax
    

A little subjective, so not sure how much I can say here. I can say that I'm
not a huge fan of our multi-line comment syntax. It's not entirely clear what
a better syntax would be though (the original issue on this had some
suggestions, but some of them were worse).

    
    
      - One-based indexing
    

I think there has been plenty said on this topic, though interestingly this is
one of the only times I've seen the argument made in a way that I actually
agree with. That said, I do think there is an easy way to deal with this
though. For packages that needs arrays of indices, it would be quite easy to
define an `IndexArray` type that does the translation automatically.

    
    
      - String Formatting
    

Yep, you're right, it's a mess. It'll have to be cleaned up.

    
    
      - Unsafe C Interface
    

There's two projects (Clang.jl and Cxx.jl) which can help with this. The
former automatically generates ccall definitions for you, the latter just
parses the header and generates the call directly.

    
    
      - Slowing down in development
    

I'm really not sure where that impression comes from. Perhaps it is that we're
adding fewer features, but rather working on cleaning up existing features.
Also, I personally at least have been doing a lot of work outside of base
(particularly on the debugger). Not sure. Would love to know.

~~~
bluecalm
The thing about 1 based indexing is that it's a kind of in your face "this is
different" decision from the point of view of a programmers of most popular
languages. To be honest I wouldn't want to start investing my time into a
language where people who proposed 1 based indexing are making design
decisions. It's not that I think they are incompetent but it's clear they care
way more about some different world than about my programming world and are
ready to make my life miserable stating the point.

Now, I don't know if people from that different world (Fortran, Matlab, some
other languages used in academia maybe) would feel the same way about 0 based
indexing but it certainly sends the message to programmers outside those
domains.

~~~
chappi42
R and Mathematica are also 1 based. And R really is popular
([http://www.tiobe.com/tiobe_index?page=index](http://www.tiobe.com/tiobe_index?page=index)
\- ok, popularity is droping right now, likely b/c of Julia ;-))

~~~
c3534l
Julia seems like it's meant to be friendly to people who know MATLAB, Python,
and R (even Fortran). R and Python are really comfortable with working with
data science and that's what Julia is geared toward. I have no experience with
MATLAB, though. Julia's programming "world" may indeed be a different
programming world than C programmers.

I'm not defending Julia per se. I've been patiently observing from the
sidelines to see how the language shapes up.

------
xixi77
Libraries? Sure. Ease of development, I cannot comment on.

But measuring performance with timing a "hello world" program? Seriously? What
scenario does the author have in mind that makes this particular benchmark
even remotely relevant?

The rest of the rant pretty much comes down to "it doesn't look like Python"
(which is IMO a good thing, and I would certainly not call Python a "de facto
standard of numerical computing" \-- sure, it's there, but I still see a lot
more of R and Matlab -- and note how both have 1-based indexes.)

To be fair, last time I checked, Julia definitely had some catching up to do
in a few areas to become a real competitor to those two, but "hello world"
benchmarks would not be among these.

It's been a little while though, and I am tempted to check again -- leaving
libraries alone for the moment, does vectorization still result in a lot of
performance loss compared to loops?

~~~
whyever
> But measuring performance with timing a "hello world" program? Seriously?
> What scenario does the author have in mind that makes this particular
> benchmark even remotely relevant?

If Julia is to replace Python in scientific computing, people will want to use
it for short plotting scripts. Startup time matters there. That hello world is
so slow is already telling. A plotting script needs tens of seconds just to
load the Julia libraries.

~~~
patrickthebold
They use the REPL like R.

~~~
argonaut
Not all of them. Many of them? Sure. Many people also use scripts and so on.

------
papaf
I know R and have used Octave. I started learning Julia this morning after a
physicist recommended it to me after he switched from python. I used
Jupyter/Julia to simulate a neuron as a practice exercise. This is my
experience as a beginner:

1\. The static typing makes a big and positive difference. Its nice having a
statically typed repl.

2\. The documentation is good.

3\. Using unicode symbols and \mu style tab completion is nice, especially in
Jupyter where you can use the same symbols in latex style equations.

4\. The base install is a bit bare. It would be nice if batteries were
included - distributions and dataframes in particular.

5\. R uses 1 based indexing and it was no shock to see this in Julia.

6\. I had no problems with the mix of lisp and C++ in the source code. The
lisp implementation is beautiful and worth a read.

Generally, I was shocked to see a blog post like this given that my first day
with Julia was so positive.

~~~
SolarNet
> The base install is a bit bare.

I think the problem here is the library approach. They should break stuff out
of Julia's core library and move them into default included libraries (like
python does).

~~~
argonaut
What is the difference?

~~~
ta2507823
* initial memory footprint is lower

* faster start up time

* cleaner global scope

------
acidflask
I'm genuinely surprised that one would say that Julia is "slowing down in
development". Perhaps it's because less press is being generated about Julia?
Or that the commit rate has gone down slightly, now that the easier issues
have been picked off and the remaining work will take longer for the next
round of incremental developments? I'm not sure what the OP meant, but from
the inside, we are busier than ever.

\- Both Julia Computing and the Julia Lab have grown sizably over the past two
years. The Lab now houses ten full-time researchers (up from four last year),
with five new students coming online over the summer and fall. We also
maintain more active research collaborations with more research groups at MIT
and off-campus.

\- Julia is a grateful recipient of 12 Google Summer of Code slots this year,
compared to 8 for 2015's Julia Summer of Code program (sponsored by the Moore
Foundation) and 4 for GSoC 2014.

\- JuliaCon grew from 72 attendees in 2014 to 225 in 2015 and we are on track
to meet or exceed last year's ticket sales for 2016.

\- New packages continue to be registered on the central METADATA repository
at roughly the same rate since June 2014.
[http://pkg.julialang.org/pulse.html](http://pkg.julialang.org/pulse.html)

By some measures we are still a relatively small project, but I don't see any
serious evidence for the imminent heat death of the Julia universe.

------
zintinio5
For many users of Julia, long-running performance matters more than
microbenchmarks. Having converted a naively written Python program to Julia
(there was a huge amount of computation being done over a large search space),
I experienced a massive speedup even against PyPy. My Python scripts ran for
about 10 hours before I called it quits (.6% of the work had been completed).
Converting to Julia allowed me to finish within 3-4 hours, AND it was easy to
parallelize.

~~~
arcticfox
Just how naively was the Python written? ~1600 hours vs. 4 hours of execution
time sounds like some extremely naive starting code. Is it fair to even
compare them?

~~~
GFK_of_xmaspast
I've gotten 400x speedups going from python to c++.

~~~
dagw
I've gotten 200x speedup going (badly written) Javascript to (better written)
pure python, despite python being a nominally slower language according micro-
benchmarks. Comparing run time without knowing anything about the code doesn't
say much.

~~~
MikeHolman
Were you using a js runtime without a JIT? Were your python algorithms better?
Otherwise a 200x speedup sounds completely unbelievable. That would basically
indicate a bug in the js runtime causing degenerate performance under your
scenario.

~~~
lqdc13
That's very believable.

Example: popping from the beginning of a list in Python is O(N). Popping from
the end is O(1). Initial poorly written code can have a lot of such obvious
optimizations.

~~~
sgt101
It's a common programming thing - you write your code, it compiles, it runs,
it runs properly on your test case, you try it on your full data, it's too
slow. You run your profiler and you spot some problems, you solve them, it's
still too slow, repeat until fast enough, declare victory.

------
tmalsburg2
Not sure why this is on the front page because the criticism in this article
is fairly superficial. Julia was designed for scientific computing and
interpreter start-up time doesn't matter at all in this context, especifically
the start-up time of hello-world. Baseline memory consumption isn't an issue
either and one-based indexing is simply something to get used to. If this
stops you from being productive, it's not the language's fault. The comments
about the syntax remind me of all those people saying Lisp is a bad language
because it has too many parentheses.

------
armamut
I love python and I don't like Julia at all.

But, I think judging a language (which claims math and scientific computing is
it's strongest point) by print screen performance is not fair.

And, the authors last example is a little bit misleading I think. The C code
sets up registers and jumps to the main sprintf routine. I don't know why
didn't he tell that routine's instructions count...

Has any one counted?

~~~
armamut
Oh. I think metrognome had shown the point. Didn't read it. sorry.

------
sgt101
I'm not bothered by "hello world" performance myself, and I my recent issues
with Julia have been caused by rapid development meaning that when I had to
put it down for a few months lots of things I had done (because I'm mortal)
stopped working. I wrote this off to "it's 0.x, getoverit". I've never tried
complex text formatting in Julia either! My concerns are more focused on the
type system (this I love) and performance for massive computation (I've still
not managed to persuade my Hadoop admin to put julia images across our
cluster, but I suppose I might win the argument one day!)

~~~
dnautics
Yeah the poor performance in this blog post is a total misunderstanding of why
and how julia is performant. Is printing "hello world" fast really that
important? OK. Then don't use Julia.

You pay for it by having the compiler JIT the code in a highly optimized
fashion. If you have actual numerical calculations that are compile-once, run-
many-many-many-times, then you will see a huge performance benefit, amortizing
the cost of expensive compilation and optimization that happens once at the
beginning of the program cycle.

The very title of what he links to "How To Make Python run as fast as Julia"
betrays the problem. The goal of Julia is to not have to do that sort of
boilerplate/arcane tweaking to get really good performance - the system will
do it out of the box.

I'll have to disagree with the notion that Julia is hard to read. I'm
currently deploying Julia to run automated hardware verification on a computer
chip. Effectively, I've written a DSL using Julia macros that generates
assembly code files, compiles, and executes it, and my coworkers (who do not
use julia) have found it easy to read my code and understand what's going on.
Far easier, in any case, than the equivalent C code using asm blocks.

I do agree about the one-based indexing. I get it, it's what matlab does. But
it would be nice to say, be able to throw an option at the top of a program
that forces the appropriate indexing.

~~~
acomjean
>The goal of Julia is to not have to do that sort of boilerplate/arcane
tweaking to get really good performance

As someone who is new to python (for bioinformatics), and find python is a
fine language... but..

The do it "this way not that way" method of implementation of the same
algorithms to get it to run fast makes writing performant python a tedious
exercise in research and profiling. The article cited suggests Cpython, numby
and numpy [1] as ways to make it faster.

Why not C using GPU acceleration as the time spent coding would probably be
the same? Thats what I love about plain python, its fast to write and has some
good data structures.

I haven't tried Julia, but someday its on my list of languages to learn more
about.

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

~~~
dagw
_Why not C using GPU acceleration as the time spent coding would probably be
the same?_

As someone who does that sort of thing I can assure you it isn't. And when I
do use C and GPU acceleration, doing so via cython and pyCUDA (and the myriad
of libraries that build on cython and pyCUDA) saves massive amounts of time
and effort.

That being said I do agree that writing fast python is quite different from
writing python, probably more so than in most other languages.

------
metrognome
When the author compares the number of CPU instructions that sprintf compiles
to in both C and Julia, he fails to take into account dynamic linking in C:

    
    
      jmp	__sprintf_chk
    

I would guess that another few hundred instructions run as a result of this
jmp. Thus, the difference in the number of instructions that C's sprintf and
Julia's @sprintf compile to are not as drastic as the author makes it seem.

~~~
3JPLW
Also note that the author asks for the native code for arguments of type
`(AbstractString, Float64)`. The first is an abstract type — which means that
this code will never get called in the first place. Julia will resolve the
type of the string, and then dispatch to the concrete implementation. Which,
for an ASCIIString, is 3x shorter.

~~~
vitaut
This is actually a good point, but what about Unicode? Will `(UTF8String,
Float64)` emit another function?

~~~
3JPLW
It's the same on 0.4, and Strings are getting a big overhaul on 0.5. Here are
the results for 0.4:

    
    
        $ julia -e 'f(a, b) = @sprintf("this is a %s %15.1f", a, b); code_native(f, (AbstractString, Float64))' | wc -l
        WARNING: Returned code may not match what actually runs.
             628
    
        $ julia -e 'f(a, b) = @sprintf("this is a %s %15.1f", a, b); code_native(f, (ASCIIString, Float64))' | wc -l
             194
    
        $ julia -e 'f(a, b) = @sprintf("this is a %s %15.1f", a, b); code_native(f, (UTF8String, Float64))' | wc -l
             194

~~~
vitaut
Thanks, this looks better. I'll need to update the post.

------
gravypod
To me the biggest thing that Julia brings to the table is the amazing
concurrency support.

You can not only easily create parallel tasks on your machine, but on any
machine that you have ssh access to that also has Julia installed.

That is simply amazing. Until something else can do that, Julia is going no
where but up in my mind.

------
Tarrosion
At this point there are many well phrased comments saying most of what I
wanted to say - unreliable airport wifi ate a long response a few hours ago -
so let me just note that

A) the author is entitled to all their opinions and experiences and

B) raises some good points (see Keno's comment) but

C) raises some subjective (syntax, etc) and odd (measuring performance by
timing a one line hello world) points.

Julia is not the right hammer for all nails, but I use it every day and enjoy
doing so. If you're on the fence, I encourage you to give it a try. And for
what it's worth, end as a keyword aside, I really like the syntax,
particularly :: type decorators. Your mileage may vary.

------
DannyBee
Complaining about microbenchmark performance, then perf benchmarking in a
completely unscientific way, is pretty bad (These are non-quiesced machines,
etc)

The error bars show it's probably slower, but i'm pretty sure he's not going
to get valid measurements to 0.002s by running it once with time without doing
things like disabling CPU throttling, etc :)

Of course, looking at julia's microbenchmark for C, they had to do a bunch of
things to get the compilers to stop optimizing away their benchmarks, so that
should tell you something right there :)

The example they give of sprintf calls is completely misleading, since
sprintf_chk is going to be several hundred instructions itself.

Follow
[https://github.com/lattera/glibc/blob/master/debug/sprintf_c...](https://github.com/lattera/glibc/blob/master/debug/sprintf_chk.c)
all the way down the rabbit hole :)

------
Fede_V
Julia aside, Keno, kudos for being an absolute class act and replying to
everything so politely.

For what it's worth, my impression of Julia has been overwhelmingly positive,
and all the developers I've interacted with have been polite and friendly. I
haven't made the switch from Python because:

\- I prefer the Python syntax

\- I like Python libraries (I know about PyCall, and it rocks)

\- The increased speed of Julia doesn't really add much given numba/theano and
so forth

However, I really like:

\- Optional static typing for sanity checking

\- Can write fast functions directly in julia - which is handy when passing
callbacks or doing numerical routines like integration (although this requires
timholy's fast lambda package)

~~~
tavert
> this requires timholy's fast lambda package

Not on nightly. That's fixed now. The technical concerns here about startup
time etc are fixable, we'll get to them.

------
Frompo
If you want to replace Matlab you should use Octave, julia is for making your
next climate model, not for "hello world" ricing

~~~
sndean
I've found the Armadillo C++ library
([http://arma.sourceforge.net/](http://arma.sourceforge.net/)) to be a better
replacement, when concerned about speed.

~~~
cozzyd
IME eigen3 is even better (although the template-induced hellish compilation
times are a huge pain).

~~~
sndean
I was going to say "but there's RcppArmadillo!" But now I see there's
RcppEigen, too. I'll have to check it out.

------
yoodenvranx
As someone who does quite a lot of image and signal processing the fact that
their arrays are 1-based is a complete deal breaker. The first few years of my
career I worked with Matlab and I hated 1-based arrays with a passion. I think
I never encountered a situation where the Matlab way makes stuff easier,
almost always the 0-based index is the more natural choice.

After I switched to Python/C I can say that I never want to work with 1-index
languages again.

~~~
mathgenius
I just cannot comprehend how anyone can use 1-based indexing. I have never
used it myself though so there's always the possibility that I may just be
missing out on something. Glad that you cleared this up.

~~~
Sean1708
I just can't comprehend how something as trivial as indexing can be a deal-
breaker for someone. I write 0-based most of the time, but I can think of as
many advantages for 1-based indexing as I can for 0-based. The only time I can
understand prefering 0-based is in C or something of a similar level, where
indexing is just syntactic sugar for pointer arithmetic.

------
daxfohl
Seems like for the last five years every language has been gaining popularity.
Now they're all losing popularity. Except rust, perhaps, and elm. What gives?

~~~
hondaz54
Obviously static/strong typing is winning. Last man standing are JavaScript
and Python, the former transforms into a compilation target (like Elm), the
latter doing some kind of gradual typing (like mypy).

I think dynamic typing has its place, but more in experimental design and
prototyping than in bigger application development (big IMHO).

~~~
unlinker
Why is strong/dynamic typing considered such a big deal?

~~~
IshKebab
Two main reasons:

1\. You can detect very common errors (e.g. typos) at compile-time instead of
_maybe_ detecting them at run-time. This makes the code much much more
reliable (or equivalently you don't need to do nearly as much testing).

2\. Dynamic typing prevents IDEs from doing extremely useful things like
_real_ code completion and symbol renaming.

If you're thinking "but I edit Javascript with code completion" or "code
completion isn't such a big deal" then it's probably because you've never used
_accurate_ code completion, e.g. Microsoft's Intellisense for C++, or pretty
much an Java IDE.

~~~
lispm
There are ways to deal with that in dynamically typed languages.

1) Common Lisp implementation use a compiler to detect typos, etc.

    
    
        CL-USER 21 > (defun bar () (fo0))
        BAR
    
        CL-USER 22 > (compile *)
    
        The following function is undefined:
        FO0 which is referenced by BAR
    

2) In Common Lisp one can ask the running Lisp system for information about
classes, symbols, functions, etc.

The use cases for renaming are also completely different. If you take for
example a Java class and you want to rename an attribute and update the
getter/setters you might want to use a 'tool'. In a dynamically typed language
like Common Lisp, this is often not necessary because code generation is
widely used and changes can be propagate that way.

------
jerf
You know, you take a potshot at Go in there, but I observe that none of the
negative bullet points apply to Go. My real point here not being "Go rocks",
but that languages are more than just the collection of bullet-point features
they claim on their home page. I think this is another one of those things
that says obvious when I say it directly, but a lot of people are not letting
it inform their actions.

Also I _love_ that first alphabet image on that page.

~~~
Etzos
Was it really a potshot at Go? Maybe I read it incorrectly but what I thought
was being said was that all the "modern" features that Julia/Python/other
newer languages have are not available in Go (think stuff like list
comprehensions). I don't think that's a potshot as it's not really a negative,
just a difference in design. Go doesn't have those features and many times
does not want those features, and there is nothing bad about that and nothing
bad about stating such.

------
doug1001
\- One-based indexing

setting aside whether zero- or one-based indexing is 'better'; R and MATLAB
have one-based indexing, so the convention is likely familiar to many in the
Julia target audience.

still, as the OP says, (relatively) painless interoperability with C and C++
is an advertised Julia feature, both of which use zero-based index (although
Fortran is one-based), and that mis-match is a definite obstacle to
interoperability.

~~~
tavert
I find I don't pass individual array indices back and forth between C and
Julia as often as I would in Python or Matlab, since I don't need as much
compiled interface glue. You can do iteration and the like entirely on the
Julia side or entirely on the C side and mostly pass the array buffers back
and forth. ccall handles that for you if you declare a Ptr{Float64} argument
type that the C library expects and send it a Julia Array{Float64} input. It's
when you have arrays of indices, like the linear programming library his
example snippet is referring to, that you notice. Or serializing text-based
representations.

------
rmah
Regarding performance, I can only say that julia's primary use case doesn't
really seem to be for small scripts that take a few msec to run.

The last set of programs I wrote in julia had run times of hours to days. A
few extra seconds of startup time is well worth the 10x or better improvement
over using python for the same tasks. The code was also tighter and easier to
understand. A win all around.

------
Gratsby
I think it's a little naive to "give up" on a language early on, but on the
same note, I've walked away from several for periods of time because they
lacked the maturity I needed.

I did enjoy the article and the linked article that spelled out ways to
increase performance with Python. With any environment there are dramatic
performance improvements to be had with a little bit of engineering and
knowledge.

I've seen a bit of an odd shift towards Julia - People seem to be adopting it
in droves from my perspective. That means that the development team is doing
something very right. Given some of the people I've heard talking about Julia,
I don't think it's going away any time soon.

This kind of feedback is good for the team. If you are going in another
direction for the time being, stating why is always helpful. Glad to see a
developer here in this thread.

------
marmaduke
Numba package for Python gives you the LLVM JIT for numerical work. I really
don't see how Julia is relevant anymore.

~~~
ska
Python really doesn't (and cannot) address many of the design goals of Julia.
At least as I understand them (and I'm not a Julia user). Whether or not Julia
has/will achieve them either is a separate issue.

Python can be a very useful mess for this sort of work (numerical analysis
etc.), and is succeeding at that quite well. In fact, that's it's main
challenge to something like Julia. Not design, that ship sailed a long time
ago. But practicality and availability of packages and bindings. Once you get
too far ahead in that, it's hard to justify using any other platform for "real
work", rather than because it's fun to hack on.

~~~
marmaduke
Python is a mess if you make it that way.

What are these design principles in Julia that Python can't possibly uphold?

------
partycoder
Diversity is good. Ruby and Python, C# and Java... good ideas can emerge.
Having another Python-like language is good.

------
max_
The author has addressed very valid issues, but I strongly disagree with his
objective theme of "Giving up"

I don't think the Julia team should be blamed for anything. I have not heard
of the project receiving any support from large companies as Python, Golang
and Rust do.

For this reason, I find it very unfair to compare Julia to these languages.
FYI Julia has not even reached version 1.0 yet!

The language just needs support, and the author is not helping out.

------
pathsjs
You may be interested in Nim. If you can tolerate working without a REPL, Nim
hits essentially all the bullet points you mentioned, from macros to
coroutines, multiple dispatch, ability to call c trivially and python easily
and so on.

It has static types and is fast. The libraries for scientific computing are
not there yet, but it lends very nicely to mathematical abstraction.

~~~
jjnoakes
How does Nim's "trivial" C interop work if Nim is garbage collected and C is
not?

(Not trolling, genuinely curious).

~~~
pathsjs
Nim compiles to c, hence you can just call c functions. All you need is a
signature, which can even be generated automatically from a c header.

You can manually allocate memory if you want, and you can also pass pointers,
either to manually allocated or gc memory. The gc will not run when c is
working, since it is triggered by allocation

~~~
jjnoakes
So if I call from Nim to C (passing a gc'd Nim-owned pointer), then that C
routine calls back into Nim (via a function pointer, or some other way through
the FFI), the nested Nim routine may trigger gc and wipe out the pointer my C
code is working with?

~~~
pathsjs
The situation that you describe could happen, but it is quite rare in
practice. Usually, I call c functions that do their work and be done, such as
BLAS.

For such cases, you can either manually allocate the pointers you pass to c,
or temporarily disable the gc. Each thread has its own heap, so gc for one
thread does not break anything in other threads

~~~
jjnoakes
It's just those "quite rare in practice" bugs that I'm concerned about. Those
tend to cost the most.

------
bjkfjgnbkfg
You also might be interested in:
[https://www.reddit.com/r/Julia/comments/3rxg1x/is_julia_movi...](https://www.reddit.com/r/Julia/comments/3rxg1x/is_julia_moving_too_fast_in_too_many_directions/cwsdc6v)

------
pkm
Lots of guesses as to what Julia can or can't do in here, primarily by peopl
who obviously don't follow the progress of the language. Slowdown? I'm
following Julia closely, and I have quite a hard time doing my job and keeping
up with commits and the issue/pr tracker at the same time. That Julia doesn't
get as much PR now that it's a bit more mature cannot be too surprising. How
many articles have you read lately about the thousands and thousands of people
who will be learning C(++) over the coming years? Not many I guess, but does
that mean C is dead?

------
Xeronate
I swear every day I see a new post about why X programming language is awful.
It is pretty demotivating.

------
leni536
About the startup time: a Julia server and client could mitigate this,
couldn't it?

------
_Codemonkeyism
Key phrase

"I became very enthusiastic about it."

