Complaining about 1-based indexing in Julia is so... 4 years old! Just use OffsetArrays, and you can use 0 based, or whatever base floats your boat (start underwater with -5, for example!)
Back 5.5 years ago, I used to complain about the 1 based indexing and the column-major structure of matrices in Julia (both like Fortran), however, those issues have been solved by OffsetArrays and PermutedDimsArrays, giving far more flexibility that is possible in most other languages.
It's silly to keep bringing up the issue of one based indexing, when you can use any integer as the base, just like Fortran 90 (so you can index by -5..5, for example).
For some things, 0 based does make things easier, sure, but you can do that easily in Julia (and more!)
One thing that is pretty great about Pluto.jl, is how responsive the author is (Fons van der Plas, or @fonsp on GitHub).
I've been able to get great suggestions from him (as well as the fast growing community of Pluto users) on Zulip discussion group for Julia (https://julialang.zulipchat.com)
I've also switched to using Pluto, shortly after seeing the presentation during JuliaCon. It is still rough around the edges, but I've found it a lot easier to deal with than Jupyter, quite frankly.
You'll also save a lot of effort in future endeavors, IMO.
Remember, once you've switched to Julia, Python is still only a `using PyCall` and `pyimport` away!
I'm having a lot of fun with Pluto.jl and PlutoUI.jl this past week, it's so easy to use and add interactivity. There are still some rough edges, but that's what PRs are made for!
I haven't seen that at all - many Julia programmers are (or were) also Python programmers.
I think there is a lot of respect in the Julia community for Python & the Python ecosystem.
There have even been a number of Julia talks at various PyCons over the past few years.
Python's ecosystem is great - but Julia's is growing incredibly fast, and in some cases Julia has already surpassed what is available in other languages (for example, take a look at the whole differential equations ecosystem: https://github.com/JuliaDiffEq).
Also, Python's ecosystem is only a 'pyimport(name)' away (using the PyCall.jl package). Same thing is true for R and a number of other languages (RCall.jl, JavaCall.jl, etc.)
I've been using SymPy, QisKit, matplotlib and other Python packages with no problem in Julia.
I've been using Julia for non-scientific computing programs for almost 5 years now, and (especially now that it is stable since the 1.0 release) have found it well suited for general programming as well.
Having a language that is easy to write (like Python), runs fast (like C/C++), and incredibly flexible & expressive (like Lisp) makes programming fun again!
I've been programming in the Julia language for the past 4.5 years, and as somebody who has lived through the problems with Julia's name (getting incessantly teased by coworkers, friends, even my wife and kids, because of how much I like the Julia language and tend to gush about my enthusiasm for it), I think @StefanKarpinski really has hit the nail on the head here.
His suggestion of "Ballet" is very good, it still conveys all of the grace, elegance and beauty of ballet. Also, ballet dancers of all genders are pretty kickass athletes as well as incredible artists and performers.
Come to think about it, maybe I shouldn't recomend them changing from "Ballerina" to "Ballet", because if I came up with a new language, "Ballet" would definitely be pretty cool, and I'd want to use it myself!
Since many C and C++ implementations use LLVM, which Julia also does, it is frequently the case where C/C++ code and Julia code when fully optimized end up performing almost identically. However, what makes me love Julia is the programmer productivity, in general I can write many fewer lines of Julia code, and get generic code that runs as fast as my optimized C code, in about 1/3 the time (so I have time to spend with my kids, or simply hack more!)
I've actually seen many cases where overuse of concrete types (on function parameters) in Julia can lead to poor performance.
For example, if functions are written declaring an argument as `Vector{Int64}`, and then people using the function end up calling `collect` (and causing a lot of memory allocations), when they had a value that was an iterator and were forced to convert it into a vector just to call the function.
Simply leaving off the `::Vector{Int64}` and getting rid of the `collect` on the caller speeds things up nicely.
Yes, if you want stability, you should never use a x.0 or x.0.0 release (even from a big company - how many people remember Windows 3.0? )
I, however, am a bit crazy, and enjoy living on the bleeding edge, and so am up late tonight hacking making sure all my packages are working correctly on v1.0.0 of Julia!
As someone who's spent decades programming in C/C++, and diving into assembly code (and writing a fair share when the compiler just couldn't do what I needed), I love being able to directly inspect the output code at many levels, including all the way down to "bare metal".
Yes, there's a lot of work to be done in the area of debuggers for Julia, but there are already useful debugging tools (like Rebugger) that I haven't seen for any other language.
I've seen quite an evolution over the past 3.4 years I've been using Julia and the 4 JuliaCon's I've attended so far.
Back at the 2015 JuliaCon, a number of us "older" professional programmers felt like we should stage a palace coup, because it did feel like the input of people who had "been around the block" a few times was not really valued. That's changed quite a lot (maybe because in the intervening years many of the core contributors have gotten their Ph.D.s and are having to live off their blood, sweat, and tears (plus lots of joy, to be sure) of producing things with Julia that people will actually pay money for). Yes, it was young and brash, but those awkward years seem to be past, and I feel the future of Julia is quite bright.
I complained also about the "cowboy" culture I saw among the Julia developers when I first started with it (people making a change directly to master, or merging there own PR without giving time for people around the world to review, or not having a minimum number of qualified reviewers before merging), but those days are gone, and I feel they've matured quite a lot in the past few years in that respect. Some of it I think was simply the great excitement that comes from being able to be so creative with the language, and a rush to get things figured out and nailed down to finally get to v1.0.
As far as projects in other languages, I don't really feel it has much to do with the languages themselves, more the type of people that particular project attracts.
Three years ago, when I found out about Julia (and quickly fell in love with the language), I not happy at all about the 1-based indices and column-major storage, and at the time, a lot of the responses I got were along the lines of "Julia is for mathematicians, and 1-based indexing and column major are just fine for us". Now, Julia is able to have indices with any base that you want, and can handle row-major storage as well (thanks to Tim Holy's great work). Why is anybody concerned about this anymore? Julia can do whatever you want, you shouldn't be stuck with languages that can ONLY do 0-based indexing.
Not true necessarily, especially with a stable v1.0 coming out this summer.
I've worked on two separate commercial products using Julia over the last 3 years already. The changes between the big releases made things difficult at times, however the great productivity and resulting performance recompensed for those problems.
Why does it have be one or the other? I think the two of them can be rather complementary.
Julia does very well at calling libraries with a C ABI, and Rust can be used instead of C or Fortran, if you really need to (although, in over 3 years, using Julia to develop commercial products, I've not once needed to use C or Rust, as I originally had thought I'd need to, Julia has met and surpassed all of my performance expectations)
I've also found that Julia handily beats any other language I've used (which is quite a few over 44+ years of programming!) at one metric that is frequently the most important to me, programmer productivity.
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.
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.