Sometimes languages get stuck by their history, and (without really becoming a rather different incompatible language) the only way forward is to start from scratch.
Also, Julia is good at letting you use those old ecosystems, C and Fortran libraries, Python, Java, R, all from the comfort of home (Julia)
I wouldn't use that as a primary example (allowing integers to overflow), because one of the great things about Julia is that it is incredibly easy to define your own types that will simply work, that for example, do checked arithmetic on integers (SaferIntegers.jl, I think is one, or don't want a limit (BigInt, which is included in Julia).
Julia gives the programmer the choice, and not only that, allows the programmer to create their own choices.
I don't feel at all that it's a fair characterization of the overall community. I'm sure I've been the target of more of what Dan Luu experienced than anyone else in the Julia community, from the same source, but I haven't let that stop me from contributing as best I can to the community, by answering questions (on Gitter and Discourse), helping with code, and by contributing my own packages to help out in areas where I felt Julia needed some extra attention.
I also think that most of the community is more aligned with the example set by Jeff and Viral. Both show great civility, patience, and a willingness to listen to others, in my experience.
Finally, with regards to the person that both Dan and I have had problems with (and I have no personal knowledge of that feud, that happened before I had discovered Julia), I respect him a lot (even if he feels I "attack" him when I try to bring up technical issues with code / designs that he's been involved with), I will always be grateful for his role in creating Julia, I think he's a great promoter of Julia, at conferences, etc., and he often has quite a lot of good, well-thought out things to say on GitHub and Discourse.
He explained that at the beginning of his post - things like the Pkg changes are getting quite a lot of press already, he wanted to highlight the things that people might not have realized were coming in v0.7/v1.0.
I believe though that there is some work being done on actually directly interpreting the AST, in cases where going through all the work of generating LLVM IR and compiling that to native code is unnecessary, particularly when it is code that is only run once when a package is compiled the first time.
Julia's JIT compilation is rather different than what is referred to as JIT compilation in other languages, such as Java or JavaScript, where the language is interpreted (which may be interpreting instructions from a virtual machine such as the JVM), and the run-time decides if some code is being hit frequently enough to warrant compilation to native code.
Julia first compiles to an AST representation (also expanding macros, etc), performs type inference, etc. When a method is called with types that haven't been used before to call that method, that's when Julia does it's magic and compiles a version of that method specialized for those types, using LLVM to generate the final machine code (just like most C and C++ implementations these days, as well as Rust and others).
That also means that it's rare for Julia to have to dynamically dispatch methods based on the type of the arguments, which is one of the things that can really slow down other languages with dynamic types.
In some sense, it doesn't really need to compete with R, many times it's better just to use the R, Python, Java, C++, packages via RCall, PyCall, JavaCall, Cxx, or use the built-in ccall to use libraries written in any number of languages that conform to the C ABI (C, Fortran, Rust, ...).
I've joked before, about how there is no such thing as a "One Language To Replace Them All", however, I feel Julia is the best candidate for the "One Language To Rule Them All", since while it solves the "two-language" problem in many cases, you can use it bind code written in many languages together (hopefully in a bit nicer fashion than the "One Ring" bound the other rings and their users!)
The creators of Julia have been focusing on technical, numerical, scientific computing first, however, the language was always intended to also be a good general purpose programming language (which it is) [I was lucky enough to attend Jeff Bezanson's Ph.D. thesis defense at M.I.T. 3 years ago - and was able to ask him that question there].
I used to be a full-time C/C++ programmer, focused on performance of large systems, however, since learning Julia I haven't had to go back to writing C or C++ even once in over 3 years, since I can write even the sort of low-level code I typically do in Julia, faster and easier than in other languages, and get the same performance.
I'm strongly considering Julia as an alternative for C/C++.
A few questions if you don't mind:
* How does Julia's GC play into the performance characteristics of these systems?
* What tools does Julia offer for fine-grained control of memory?
* It appears that Julia uses a rich runtime, do you notice it "weighing down" on performance?
* Do you ever feel the need to drop down to C/C++ for hot code paths?
I do have to be aware of the GC, and try to use techniques to avoid lots of allocation.
I haven't needed much in the way of fine-grained control of memory, what sorts of things were you looking for?
A lot of that "rich runtime" (i.e. including the kitchen sink for linear algebra stuff) has been moved to stdlib, but still packaged with Julia, but even before, it really didn't seem to affect performance except for slowing down the time to build julia (esp. on the Raspberry Pi!).
In over 3 years, I've never needed to write anything in C/C++ (except a couple of times I wrote something out in C just to demonstrate the Julia was generating as good or better code (and I mostly write rather low-level stuff).
I have it in mind to learn Rust, which I think would be much better than either C or C++ for that sort of stuff (to make a small robust library of functions for some hot code paths), and it integrates well with Julia (using ccall), but the day that Julia's performance hasn't been good enough as not yet come, at least not for me.
Thank you! I was not looking for anything in particular. Julia's design is everything I've been craving from a language; good performance seemed too good to be true. Due to never having worked on large systems, my judgement is of limited use. Your feedback convinced me to take a serious look at Julia. Looking into the discussions regarding Julia's implementation (so cool that they are easily accessible on GitHub/Discourse) convinced me to commit to learning it.
Julia has improved quite a lot since the "Giving Up on Julia" blog was written, and even back two years ago when he wrote it, he'd missed some packages that would have solved his issues. I'm very glad that Tom has taken the time to address this.
I still feel that Julia has a great future, and things will accelerate as soon as v1.0 is released.
