Relevant quotes from the slashdot summary (couldn’t easily find the time point for this in the video):
Go and Julia: "I still think that Go is a very interesting language too. Of all the new languages, Go is probably the most Python-ic — or at least the general-purpose new languages. There’s also Julia, which is sort of an interesting sort of take on something Python-like. It has enough details that look very similar to Python that then when you realize, ‘Oh, but all the indexing is one-based and ranges are inclusive instead of exclusive,’ you think, ‘Argh!’ Nobody should ever try to code in Julia and in Python on the same day.
[…]
“My understanding is that Julia is sort of much more of a niche language, and if you’re in that niche, it is superior because the compiler optimizes your code for you in a way that Python probably never will. On the other hand, it is much more limited in other areas, and I wouldn’t expect that anybody ever is going to write a web server in Julia and get a lot of mileage out of it. And I’m sure in five minutes that will be on Hacker News with a counterexample.”
The choice of 0 or 1 by itself doesn’t matter much but having to frequently mentally translate between them seems error prone. Otherwise, not much substance in that quote.
Interesting take. Just today I had to do that (code in the Python and Julia on the same day - and Matlab for that matter) and realised why Python has the non-inclusive range. Loops can be directly translated with the shifted start index:
Python: 0:len(array)
Julia: 1:len(array)
will both do the right thing.
And in my niche, maths and engineering, 0-based indexing just feels wrong to me - which is one of the reasons why it was so difficult to convince my colleagues to switch from Matlab. With Julia’s syntax being so close to Matlab, that should be a lot easier.
I think it’s a common mischaracterization of Julia that it’s for the technical computing niche only, and less useful for other areas (web servers were mentioned in this case). This probably comes in part from Julia’s own tagline, which is unfortunate. But also from surface level observations like 1 based indexing being known from Matlab, so other Matlab properties are just also attributed to Julia (and I guess you really wouldn’t want to write web servers in Matlab).
But look at some main properties of Julia:
Multiple dispatch: Yes it maps nicely to math but the code composition and simplicity of implementation it enables is useful for every application.
Simple array syntax and inbuilt broadcasting: Again, really useful for technical purposes of course but aside from linear algebra, everyone can use multidimensional containers for all kinds of code. I miss having simple multidimensional structures available when coding non-numerical things in Python, because you are not really supposed to put any arbitrary object into numpy arrays. Not having to vectorize but being able to at will with the dot syntax is so powerful.
More functional than object oriented: Yes we don’t use classes and inheritance, but that doesn’t limit what you can build. It’s not like general software applications have to be written in OO style. If someone has never programmed anything worthwhile with multiple dispatch and makes sweeping comments about the lack of OO, I can’t really take that seriously as the differences in applied scenarios are much more nuanced than it appears at first.
So to sum it up, it just gets a bit old to talk about the same surface features of Julia again and again, as if there wasn’t a much deeper conversation to be had. Most attention should go to those with actual projects to show, not just opinions.
It is my understanding that Julia is aimed at the compute-intensive ’niche’. The data-intensive ’niche’, not so much. A quote from Designing Data Intensive Applications by Kleppmann:
“Data-intensive applications are pushing the boundaries of what is possible by making use of these
technological developments. We call an application data-intensive if data is its primary
challenge—the quantity of data, the complexity of data, or the speed at which it is changing—as
opposed to compute-intensive, where CPU cycles are the bottleneck”
“My understanding is that Julia is sort of much more of a niche language, and if you’re in that niche, it is superior because the compiler optimizes your code for you in a way that Python probably never will. On the other hand, it is much more limited in other areas, and I wouldn’t expect that anybody ever is going to write a web server in Julia and get a lot of mileage out of it. And I’m sure in five minutes that will be on Hacker News with a counterexample.”
I think this is the best template for talking about gripes. This is my version.
My understanding is that Julia is sort of much more of a niche language, and if you’re in that niche, it is superior because the compiler optimizes your code for you in a way that Python probably never will. On the other hand, it is much more limited in other areas, and I wouldn’t expect that anybody ever is going to wrap a popular C/C++ library with full of features in Julia and get a lot of mileage out of it. And I’m sure in five minutes that will be on Hacker News with a counterexample.
I write Julia and Python every day, using PyCall and PyJulia.
Indexing is not a problem at all. I almost never use explicit indexing anyway – if you’re iterating over a collection, there are much better ways to do it in both languages.
In general I can’t think of anything that trips me up when switching between them – the syntax is pretty similar for a lot of stuff, and there are no big cases where something in one language is valid syntax and means something radically different in the other.
Regarding this point, I have struggled myself not with the lack of OO in Julia, but by a lack of a good overview and description of alternatives that allow one to gradually move from an OO style to more “native Julia” style, while still maintaining performance and relative code simplicity. Since an OO approach is not very relevant when working in Julia you’re left a bit in the dark when moving from another OO language, like C++ or Python, to Julia as for the former there’s an enormous amount of material available online on OO techniques. The book “Design Patterns and Best Practices with Julia” that @Tamas_Papp recommended to me in a different thread does give a nice overview of approaches and is definitely recommended, but 1) you have to know about its existence and contents and 2) subsequently purchase it (I did). It also doesn’t really go into real-world performance issues, but stays fairly theoretical with toy examples (which arguably from a didactic standpoint makes sense).
The discussions on this forum on alternatives to OO in Julia show, at least to me, that they usually involve a much deeper understanding of Julia and use of more complex features to get good performance. The thread below is a really nice example and interesting discussion of OP and a second user later in the thread try to port some fairly simple and straightforward C++ code to Julia and initially running into issues with respect to performance (getting rid of allocations). But gradually the thread turns to discussing possible code structures on how to practically mimic things like dynamic dispatch, especially when the number of classes grows:
Things suggested in the thread are union splitting, macros for field inheritance, eval to generate a set of functors, GC.@preserve and FunctionWrappers.jl. And this is just for porting a simple C++ hierarchy. While in contrast doing this kind of OO in C++ is easy by writing your class hierarchy and (virtual) methods per class and you get good performance and a straightforward code structure, without having to use any advanced features. And you only need to worry about performance of dynamic dispatch in a few pathological cases in C++, otherwise it just works fine. You can argue that OO as a modeling tool is not as good or flexible as multiple-dispatch, but I’m not convinced yet that in Julia an alternative is available with the same performance when coupled with similar code simplicity. It seems you just need to work a lot harder in Julia, while leading to more complex code.
On the other hand, it is much more limited in other areas, and I wouldn’t expect that anybody ever is going to write a web server in Julia and get a lot of mileage out of it. And I’m sure in five minutes that will be on Hacker News with a counterexample
The choice of web servers as something unfeasible in Julia is particularly unfortunate. As far as I understand, projects like HTTP.jl or Genie.jl (just to name a couple) are mature, they are used in production, and they certainly required a fair amount of work to get to their current status. They are not some kind of arcane Hacker News counter-example.
I’m curious if JuliaCon will have some talks from companies who used those systems in production and want to discuss their experience. I would definitely be interested to hear about that.
Imho the level of maturity is not yet competitive with alternatives, for the core frameworks or their ecosystems. I’m sure over time the Julia web stack will continue to develop, but it still has some work to do on reliability, performance, and interoperability.
It’s probably the most complete wrapper of Sundials that’s out there, and we have gotten good mileage out of it (at this point though, since QNDF now outperforms it, it’s just there for benchmarks, but even that is good for having the full setup so the benchmarks are fair!). Don’t underestimate the power of metaprogramming in this space (Clang.jl is awesome)
I also use Julia and Python daily, and don’t have much problem switching. If anything it forces me to think about indexing so it’s quite rare I discover an off-by-one error.
A more common pitfall is going to Python and typing using rather than import, then getting used to import, coming back to Julia, having import work but not bring what you wanted it to into scope, getting used to using, repeat.
In 2021, why are you commonly specifying indexes? That just seems wrong. It shows up, but I would think using foreach style things and broadcast should be far more common.
Imagine 20 years later, Jeff Bezanson does this kind of interview.
