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.
Just in the last few months BinDeps was broken by a "deprecation fix" that was completely wrong and using a name that didn't exist, and it got merged and released by the patch author before anyone else could look at it, breaking many downstream packages.
Refactorings and major changes in ZMQ.jl and the web stack similarly get merged and released immediately with zero review, still. This is a major problem.
Features in the base language have been deleted during 0.7-DEV because a single core developer didn't like them, despite multiple other core developers voicing disagreement that the features were useful and removing them was not urgent or necessary.
It's not a development culture I would rely on when products and money and jobs are at stake. Even the startup you were working with abandoned julia, correct?
> Just in the last few months BinDeps was broken ...
What I don't understand is why you didn't just stay with old stable versions? You wouldn't be exposed to such issues, wouldn't you?
> It's not a development culture I would rely on when products and money and jobs are at stake
On the other hand this 'development culture' has brought brilliant results in a relatively short amount of time with a relatively small team.
There was a talk [1] at the Juliacon 2018 where a company very successfully replaced an IBM product with Julia code. At 48:07 there was a question 'about problems with changes in Julia'. Answer: they started with v0.3 and 'didn't really have many problems'. They 'didn't use anything particularly exotic'. So, yes, I'd say if you adapt to the given situation it can (could have) work(ed).
I'm not convinced that a non-cowboy style would have been better. (And besides, this doesn't come free moneywise).
These incidents were with respect to 0.6-supporting versions of packages. Pinning is a good idea for reproducability but it's not the default, so updating packages or new installs are broken when careless things make it instantly into a release.
Talk to me when google, amazon, microsoft, facebook etc are publicly using and officially supporting julia on cloud platforms or even infrastructure libraries like protobuf.
The carelessness isn't responsible for or helping anything. A good diffeq and optimization suite have been built despite the prevalence of careless practices, not because of them.
It's not a question of money either, just patience and code review and recognition of how many things downstream are going to be affected by mistakes. You'll save more time in not having to put out as many fires than it will cost to slow down and not be in such a rush at all times.
I was not expecting the change to MDD (Marketing Driven Development) at the last minute. But at least 1.0 is out, I hope those wild west times, get past far behind us now. I'll wait for Julia 1.1 and most packages at 1.0 before diving back in.
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.
Thanks for the reply ScottPJones. I've seen your name pop up in multiple Julia discussions and am eager to hear more from you. In another comment you've said that you've used this in two separate commerical applications. Can you share the use cases that your commerical applications tackle?
I do need to choose one, given the time and budget that I will have to work on this. I do understand that if there are things that I cannot do in Julia, I would be able to call out to a Rust shared library using FFI, but I don't expect my use case to need it. I'm likely going to have to build a library that can be called from Julia/Python/Java etc. The question is whether to build that library in Rust or Julia. Rust has more solid C ABI support at the moment. But I'm hoping PackageCompiler.jl and other niceties come along and make the Julia shared library interlop better too.
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!