Most times a julialang.org blog post is posted to HN, I wonder whether the choice of content is well chosen to spread awareness of and interest in Julia.
I write this as a huge Julia fan; I use Julia daily, and it is both my favorite language and the language I know best. So I already think Julia is great. But reading many Julia blogs, especially those from julialang.org, would make me think Julia is only useful for very narrow scientific applications if I didn't already know better.
I like Julia because it's extremely fast and extremely expressive - and I don't just mean "expressive" as in "can be written like a dynamic/scripting language," though it can. I mostly mean that the combination of its type system and multiple dispatch allows some really elegant abstractions.
> Most times a julialang.org blog post is posted to HN, I wonder whether the choice of content is well chosen to spread awareness of and interest in Julia.
That is the area of expertise by the creators, but that puts it on the rest of us Julia fans to promote Julia as a general purpose language and talk about how we use it. I am not a scientist but I find Julia very useful for all sorts of practical stuff. E.g. people seldom talk about how great Julia is for writing shell scripts.
...compared to Python, under some circumstances, disregarding startup time.
Don't oversell it. Don't confuse what Julia aspires to be with what it is, or you'll just turn people off when they feel they've been misled. There are extremely fast ahead-of-time-compiled languages that would have finished their computation while Julia is still JIT-ing its kernel.
Julia startup time is 0.5 seconds on a very weak laptop. That's comparable to the JVM, which is nevertheless fairly popular. You may not want to write command line tools in Julia, but there's not much else that's a serious problem since process startup time is rarely that big of a performance issue.
Disregarding JIT time, Julia is as fast as compiled languages – we benchmark against C and Fortran and don't grade on a curve. This is not an aspiration, it's a well-established performance characteristic in both benchmarks [1] and real-world applications [2].
Regarding JIT time, it's important to understand that this is a fixed cost – for any computation that takes long enough to matter, the time taken by JIT will be a negligible fraction of the time. The reason to exclude JIT time when benchmarking is because most benchmarks don't take much time – tens of milliseconds, compared to which JIT is significant. But we don't actually care about the speed of things that only take tens of milliseconds – we're using benchmarks to extrapolate to things that take much longer, which is why you exclude JIT.
When I last used it, the time to import even two modules was many seconds. I know that's JIT time, but that breaks the flow of developing with Julia like it's a dynamic language. And the JVM is popular, yes, but nobody would call it "extremely fast", particularly for interactive use, because of its startup time.
The time to parse the data I needed was many minutes, slower than Python. Restarting a Jupyter kernel would break my flow every time.
The benchmarks are all for numerical computing, where the hard work is typically offloaded to a BLAS library anyway, and don't involve strings or dictionaries. Let's see a JSON parser in there and not just a Mandelbrot set.
> The benchmarks are all for numerical computing, where the hard work is typically offloaded to a BLAS library anyway, and don't involve strings or dictionaries.
I built an in-memory relational query compiler in Julia which keeps up with Postgres on the Join Order Benchmark.
Last I checked there were still some limitations around stack-allocation of types containing pointers, which is occasionally painful, but other than that it gave me all the tools I could possibly want.
The startup time is annoying, but I typically use Julia from Juno and I restart at most a couple of times per week. Ctrl-shift-enter recompiles the current module, which is usually all I want.
I also stopped using after 0.3 and tried it recently again to speed up some NLP code in Python3 and it hasn't been faster than Python3. Back then I didn't like the poor support for pyjulia, slow string processing, people using unicode symbols as variables, module import system, lack of libraries for more obscure NLP algos, and startup time. I know these aren't major issues for the core users of Julia, but these were my concerns.
The way I wrote the current code in Python was abusing sets and dicts a lot to take advantage of those fast data structs. Rewriting in Julia was fun because it was different and because multiple dispatch is fun.
However, it was roughly the same speed as Python. Ended up sprinkling some Cython on top of Python and resulted in 10x speedup. Didn't take much time to add types/pass pointers instead of strings to functions. I am not at all familiar with C++/Cython.
I think even if they speed strings/dicts up by a lot, there seem to be lots of breaking changes between releases so I wouldn't try it for something big.
I think if Julia is to succeed in the near future in the same way Python is successful for data science, it needs to be more usable for general tasks. Things like web servers, fast JSON parsing, maybe static binaries or easy parallelism. Basically, some more selling points. So far, for me personally Python is faster and easier to read for most of the things I write. At least given comparable amount of work.
A LOT has happened since then. For such a young language which hasn't even reached version 1.0 yet you can expect a lot of changes still.
You should seriously try out Julia again. I think it really works well now. I used to have a lot of issues with it before. Stuff would break, slow startup times etc. Today I don't really have any complaints.
Ok I got a few small ones. The limits on the ability to redefine stuff as you develop in the REPL can be a bit cumbersome.
0.3 was quite some time ago – string performance was certainly a problem back then (an acknowledged one). String performance on 0.6-alpha, released last week, is very good. It should now be at least as good as scripting languages that have traditionally focused on strings (Python, Ruby, Perl). There are a few more tricks we could do in the future that could make this even faster, but they involve a fair amount of GC trickery, so we'll have to see.
I really like the language, and I've recently used Julia in a scientific computing project, but the experience leaves much to be desired (and I'm certain it will be improved).
Startup time isn't the biggest problem, although it is nowhere near "comparable to the JVM". The JVM will start cold, load a Hello World application from a JAR, run it and shut down in 60-80ms. A Julia Hello World app would take at least a second, even when precompiled into a native executable.
The biggest problem, IMO, is packaging and deployment. I used BuildExecutable, which works OK most of the time (although startup times are still slow), but it results in so many shared libraries, with no easy way to cull them. Without BuildExecutable, I couldn't even find documentation on how to deploy a Julia app as a self-contained program (even not precompiled, but in a way that doesn't require Julia to be installed on the user's machine).
My setup is dead simple. I'm on Windows, so I use Notepad++ with syntax highlighting as my editor and do a lot via the REPL. I just use regular Julia, not JuliaPro. Installing packages hasn't been a problem for me, just Pkg.add("PackageYouNeed"). I've had very few problems with package setup in the past and none recently.
On a 4-core CPU I have the environment variable JULIA_NUM_THREADS set to 3 so that when Julia is doing threaded worked there's still a core free for web browsing.
One potential gotcha: the Julia docs will mention that you can access shell commands from the REPL by starting your line with a semicolon, e.g. ;ls. For me this only works if you start Julia from something like Git Bash, not cmd.
Lots of people seem to like Juno (junolab.org) as an IDE. The team behind it has made incredible progress recently, and sometimes I use it for its GUI around the debugger, but for the most part I tend to stick to Notepad++.
I write this as a huge Julia fan; I use Julia daily, and it is both my favorite language and the language I know best. So I already think Julia is great. But reading many Julia blogs, especially those from julialang.org, would make me think Julia is only useful for very narrow scientific applications if I didn't already know better.
I like Julia because it's extremely fast and extremely expressive - and I don't just mean "expressive" as in "can be written like a dynamic/scripting language," though it can. I mostly mean that the combination of its type system and multiple dispatch allows some really elegant abstractions.