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.