[wbhart]

This very much depends on what you want to do with it and what your background is. Here are some things that might bother you.

* Julia's approach to OOP is via multimethods, not the usual class/inheritance model. This might be annoying for people who don't want to learn how to be an effective programmer in the other paradigm.

* Julia's garbage collector is not generational/incremental and in some corner cases, GC can take 10 times longer than the actual function you are running (typically it is between 5% and 50%). This would make Julia unsuitable for HFT, real-time games, web browsers of the future and other real-time applications. (Edit: see Viral's post in the same thread. Incremental GC is in the works. This is genuinely my experience of Julia to date. No sooner do you need something, and someone competent is already working on it, if they haven't already done it!)

* Julia sucks at predicate dispatch. It doesn't have it. Granted, neither does any other language except Gap and one other I forgot. So if you are used to that feature, you would find Julia a step down. (Edit: yes of course Julia does not need/want predicate dispatch. It's just an illustration of something that could bother you if you were really, really used to something. I just happen to have colleagues who really are used to this.)

* Julia is tied to LLVM, so if you want to be on the CLR/DLR or JVM, you are out of luck.

* Julia currently doesn't have static compilation (I hear it is being actively worked on). This makes it more difficult to deploy binaries.

* Julia does not have Haskell-like separation of effects from pure functions. This might not appeal to type purists.

* Julia functions can fail at runtime where statically typed/compiled languages would pick up the errors at compile time.

* As popular as it is, Julia is still not in the top 50 programming languages by measure of usership.

* Julia's support of mutable C-style structs allocated on the stack, as opposed to pointers to heap allocated objects is still somewhat lacking. This creates some challenges in efficient C FFI in corner cases, especially in combination with GC.

* Julia doesn't have inheritance of data types (it is really a dual to a data focused language, which is sensible -- you typically have far more functions than data types in a program -- but it's still hard for traditional OOP users to get used to).

* The Julia abstract type system is somewhat linear, which makes it a little less flexible as far as contracts/interfaces are concerned, if you choose to implement things that way.

Of course Julia has so many features that make it worthwhile, that it is worth investigating for many projects. It has multimethods, (static) dependent typing, very easy and efficient C interface (soon C++ interface), C-like performance is possible, garbage-collection, macros, runtime console (REPL), great numerical features, Jit compilation, a good selection of libraries/packages, a package manager, profiling, various development tools, a good (highly intelligent and helpful) community.

[ViralBShah]

Static compilation is not too far away:

https://github.com/JuliaLang/julia/pull/8656 https://github.com/JuliaLang/julia/pull/8745

Being tied to LLVM is real, but we do have JavaCall.jl to call Java code.

https://github.com/aviks/JavaCall.jl

[srparish]

* lack of threads: they do support multiple processes which can be useful for splitting up work for large computation, but not a substitute for threads

* module compilation is not cached, so if you use very many modules your start-up times can be slow

* error messages sometimes require some head scratching. For example, it's not uncommon to get an error that there's no available function convert(::SomeType, (Some, Args)) when there's no obvious convert() to be seen in the code in question. Occasionally the stack trace will be missing from errors, or there won't be a line number. Obviously this is improving quickly, but can be frustrating.

[simonster]

The first two are both WIP. Threading is https://github.com/JuliaLang/julia/tree/threads (although it hasn't been updated in a little while) and static compilation of modules is https://github.com/JuliaLang/julia/pull/8745

[srparish]

That's great to see. It's sometimes hard to keep up with everything that's going on. Incidentally I really got a kick out of the recent s/Uint/UInt/ rename (https://github.com/JuliaLang/julia/issues/8905). It took a day or so to propose and do it. To compare, java will probably never fix it's spelling oddities (for example int and Integer). Very refreshing to see fundamental things like that be fixed and so quickly!

[StefanKarpinski]

Just to play devil's advocate about the Java capitalization, I suspect the difference between `int` and `Integer` is quite intentional: `int` is a "primitive", immutable value type, while `Integer` is a class. Since by convention, Java's classes are capitalized, while its primitives are spelled the way they are in C, there's some sense here.

[ViralBShah]

Our error messages do require a fair amount of work and so do line numbers in stack traces. Keno's debugger is almost ready though, and will greatly help.

[phkahler]

Arrays are indexed starting at 1. I asked about this and Jeff said it just depends which types of problems end up having to use +1 or -1. I said anything mod n is now going to have the +1 and he actually paused for quite a while. I know it's an unsolvable debate, but I thought indexing from 1 went out with Fortran. I also would have thought the math folks would prefer to start at zero.

[RogerL]

Don't forget matlab starts at 1. R starts at 1. Mathematica starts at 1 by default, though you can override that for any given array.

1-based indexing is very common in mathematical software.

[stan_rogers]

Indeed, zero-based indexing is sort of a ridiculous concession to the hardware (whether that be data/address line labelling by power of two or offsets from a memory location) if bit-twiddling isn't your goal. (Even binary operations don't necessarily imply bit-twiddling at the conceptual level, even if that's what's going on under the hood.) We've just become rather used to counting by calling the first thing zero (and somehow have managed to forget that we had to learn that).

[Ntrails]

Having started in Matlab I still regularly forget that indexes start at zero in c# and end up with errors. I feel like either option is just catering to user preference at this point, as I don't feel there's a conclusive winner logically.

[one-more-minute]

For me it's less about saving characters overall and more about making things as simple as possible in the basic case.

I'd much rather have +1 scattered throughout my code (though I tend not to) than have to do -1 in my head at the repl, personally.

[lebek]

What a fantastic list. And just to echo what the parent said, I find this so much more interesting than a list of 'good parts', which are generally easy to glean from the official docs.

Back to Julia: lack of CUDA support was a limiting factor for me when I tried it a year ago.

[ViralBShah]

The JuliaGPU organization pulls together projects that address this:

https://github.com/JuliaGPU

However, we personally feel that the path Intel is taking with Knight's Landing, is likely to be the best of both worlds - GPU and general purpose - assuming it materializes for real in 2015.

[lqdc13]

Dictionary performance is still slow from what I can't tell. Like 2x slower than Python last time I checked.

https://groups.google.com/forum/#!topic/julia-users/hxfR70Ro...

I also find the dataframe library to be much harder to use/not much faster than pandas.

Great community though.

[johnmyleswhite]

Right now, DataFrames is handicapped by problems with how DataArrays was designed. With some revisions coming in Julia 0.4, it should be possible to fix a lot of the worst problems (esp. performance) with DataFrames.

[ViralBShah]

The combination of DataFrames and multi-threading will be really amazing, when we get there. I personally use it quite regularly for production work, over pandas - and as John says above, with Julia 0.4, DataFrames will be much better.

I think that being not faster than Pandas is pretty good, since it is written in C and heavily optimized.

[tomrod]

The dataframe dev is really responsive though. We worked through a bug together a few weeks back. Nice experience overall.

[sveme]

Something I love about Hackernews: the dataframe dev actually wrote a sister post to yours (John Myles White).