I’m very glad to hear that from a core dev!
OK, I remembered what’s going on here. In julia, some collections have an n-dimensional shape (i.e. arrays). The idea is that if you pass shaped collections to map
, then the shapes must match. But that’s not happening for map(+, 1, 1:2)
, so I can agree that’s a bug.
So glad to hear that, I’ve always really hated that syntax. It’s worryingly common, so I suspect a lot of people will be up in arms if you deprecate it in 2.0, but I think you should anyway.
Should I split this whole thread after the initial post off into a new thread entitled “Gripes”?
Nothing wrong with a good gripe session (that’s why we have a gripes channel on Slack), but this hasn’t got too much to do with the original post.
If they give a deprecation warning well in advance… Ok, people still are going to not like it, but at least this is easy to fix automatically.
I think this is a very good point: if you are sure that only you read the code, it does not make sense to use a code formatter. In collaborative projects, however, I think canonical automatic code formatter does make sense because now the code is for communicating with the machine and humans.
We’ve all been busy building things and solving problems with Julia, but sometimes good news is just good news and we deserve a minute to enjoy. It really doesn’t look like the authors of the report had all these super technical details in mind
For somebody taking a first look at the language, it might look enormous. I recently downloaded the v1.1.1 manual for offline usage and it’s nearly 1200 pages!
Julia also has powerful and not so common language features. For instance, being able to construct your own array types by extending AbstractArray
is fantastic! Combine that with all the needed informal interfaces, and supporting broadcasting and vectorization, and you start to get an idea of the power and complexity involved (though to be honest I don’t think to implement all this is complex, it’s quite straightforward, but it’s a lot to take in and learn in one swoop in order to be able to do these things).
Finally, the language has so many great high-level features that it’s really difficult to stop at one – which makes it difficult to define it in an elevator pitch kind of way, again, making it look, well, enormous. (If anybody has a good way of defining Julia in one phrase, I’d like to hear it, would be super useful when people ask).
But again, the fact the Oreilly promotes the language, given all the data they have and the interest for various technologies, is just awesome.
I agree wholeheartedly. When I started using Julia, I saw its potential and went “all-in” by basing my entire research code on Julia. Nowadays I am discussing with colleagues, if we want to teach numerical courses in Julia instead of Matlab. How cool is that?
I always enjoy reading articles where Julia gets more attention.
Isn’t “Walks like Python, runs like C” sort of the slogan, with “Feels like Lisp” sometimes stuck in the middle?
Maybe expand it to something like this: “Julia is a general-purpose, interpreted language with syntax similar to Python, numeric features similar to Matlab, metaprogramming and type system similar to Common Lisp, and a JIT that can produce machine code which comes within a factor of two of C’s performance.”
Yeah, yeah, I know Julia has hygienic macros, and it doesn’t say anything about that distinctive whiff of Perl/Ruby/Bash approach to stringy-scripty stuff, or the CFFI. Have to cut it off somewhere, and I feel like these points are sort of the big ones.
Look at this cheatsheet (posted here a couple weeks ago). Why people insists in saying that the syntax is similar to Python while it’s obviously (at least the basic syntax) that it’s so much closer to Matlab?
I think when advertising Julia one should explicitly advertise arrays. Everything about arrays in Julia are just vastly superior to those in any other language I’m aware of, at least for the default, most-widely-used implementations. The fact that you can write a custom array type in just a couple of minutes is incredible. The ability for array operations to dispatch on the element type of the array, so that I can, for example, easily write efficient sparse matrix multiplication for sparse arrays of JuMP variables is incredible.
One day I realized I was going to have a lot of matrices with a huge number of columns, but many of the columns were repeated and my matrices would have been huge in memory. I wrote a custom matrix type ColRefMatrix
where this huge matrix simply references the columns of an underlying tiny matrix in a few minutes. You can also really go nuts with LazyArrays.jl and FillArrays.jl. You can even have infinite dimensional arrays.
I don’t know, maybe I’m just too deep in it and array implementations in other languages are a lot better than I think they are, but as of right now few things give me more joy than arrays in Julia.
I believe that’s because this cheatsheet deals primarily with numeric and array operations. In fact, a rather large portion of the operations they address don’t even exist in pure Python and are supplied by NumPy. Small wonder Julia is more like Matlab in operations for which Python provides no syntax. The section on “programming” reveals more similarities to Python. Additionally, this section barely scratches the surface of general programming features. They don’t get into anything to do with comprehensions/generator expressions, special string literals, type creation, type declarations, inheritance and any other number of other general programming features. That’s fine, given that the audience for this cheat-sheet is ostensibly more interested in numeric features, but it only represents one workload that Julia is designed to address.
Of course, the syntax isn’t only based on Python, and there is obviously a huge influence from Matlab for math stuff, as well as some very obvious influence from the Ruby, Perl and BASH.
Anyway, I think the influences from both Matlab and Python on Julia syntax are huge and undeniable, which is why I mentioned both in my proposed elevator pitch.
I also think it’s important to mention similarities to Python in a short pitch because it’s something many people are familiar with. Sort of a “lowest common denominator” of dynamic interpreted languages.
I agree that the array capabilities in Julia are fantastic, but I would add that the ability to easily implement custom array types in Julia is more a side-effect of the power of its type system and a few well-designed types in the standard library than specific language features related to arrays. It’s a testament to the flexibility of Julia’s design.
I have recently been trying to learn Rust. I wish the Rust manual made half as much sense to me as the Julia manual. I find the Julia manual to be well laid out, and finding what I’m looking for rather straight forward. Maybe it’s the fact that Julia and multiple-dispatch is such a new concept for most, that explaining how it works and how parametric types are constructed seemed necessary. In the case of Rust, it seems to just assume you understand how OOP works, and this is the Rust syntax for what you already know.