The Accelerating Adoption of Julia

https://lwn.net/SubscriberLink/834571/e8d7adc0d9b669bc/

by chmaynard • 6 years ago

316 253 6 years ago

7thaccount2• 6 years ago

Julia is pretty neat, but I'm still using Python at the moment for numerical computing work. Julia does have built-in sparse arrays, but I don't think it's on par with scypy.sparse yet.

adamnemecek9• 6 years ago

The nice thing about julia is that its much simpler to roll your own things. With numpy, you might have to be writing C.

andi9992• 6 years ago

But then writing something in C is not really difficult isnt it? (The real difficult part is the algorithm not the implementation in a language)

coliveira2• 6 years ago

Just the opposite, because more people know C than Julia.

marmaduke25• 6 years ago

With numpy, you might have to be writing Python

FTFY cf Numba

http://numba.pydata.org

stabbles7• 6 years ago

I would assume scipy uses MKL, and Julia has wrappers for that too: https://github.com/JuliaSparse/MKLSparse.jl. For the GPU CUDA.jl has support for sparse matrices as well.

7thaccount2• 6 years ago

My only problem too is I just want to write high level mathematical code and have it work. With Python's anaconda distribution, I just download it and the sparse stuff works. I don't want the hassle of dealing with wrappers and code that is not very mature. I know it's a chicken and the egg thing.

spacedome8• 6 years ago

I think the functionality of Julia's sparse arrays is mostly on par with scipy.sparse, it's just a bit rough around some edges still, and spread out into non-base packages (e.g. into IterativeSolvers.jl, ARPACK.jl, MUMPS(*).jl etc) of various maturity. Having the sparse arrays built-in might (hopefully) lead to a large ecosystem of interoperable sparse packages, but as with much of the Julia ecosystem this is still a work in progress.

Personally, working on sparse eigensolvers, my only complaint is that IterativeSolvers.jl is still somewhat lacking (though the ARPACK.jl bindings are more comparable to what scipy does), but otherwise cannot imagine going back to python for this kind of low-level numerical research. Having code run comparably to fortran speed (barring some memory annoyances) is huge for working on numerical algorithms.

marmaduke25• 6 years ago

Julia looks great but in practice I can pretend it doesn’t exist without much worry. Python and MATLAB are good enough for interactive work and for the performance stuff we use CUDA or similar directly.

Edit just to mention that Numba solves by and large the middle ground for the domain I work in, despite what Julia proponents have to say.

bachmeier2• 6 years ago

Julia looks great but in practice I can pretend it doesn’t exist without much worry.

That's always the problem with a new programming language. The target for the language is the people that already have something that works. Then a decade passes and that language is no longer a shiny new object, so enthusiasm for it dies, it's just another old language with warts.

teorema2• 6 years ago

Not to sound dismissive but I remember when that was true of Python (vis-a-vis Perl and some other things). My recollection of discussions on forums when it was starting to gain mindshare were arguments largely about the aesthetics of the syntax.

Numerical computing is something where there's always been something that works. Before Python it was C and Fortran.

The problem people ran into is that when everything is wrapped around low-level libraries for speed, you eventually run into the catch 22 of using the slower language that you prefer for clarity, or the faster one that makes it acceptable performance-wise.

In other words, with Python, to get the performance you would have got in C or Fortran, you have to code in C or Fortran. Then you're not using Python anymore. The idea (in theory, and a lot in practice) with Julia (or Nim, or other LLVM-targeting languages) is that you don't have this penalty.

So in that sense Julia is providing something that isn't working in Python or Matlab.

I think Julia's not quite what it's cracked up to be, but mostly it is, and I'd probably prefer working with it over Python or Matlab for numerical stuff.

agumonkey• 6 years ago

Being stuck in the middle like this can be a difficult if not deadly issue to resolve.

socialdemocrat3• 6 years ago

Everything is possible with enough effort. People wrote games in Assembly language too in the past. The thing though is that as long as the domain you want to work in has Julia packages, there is a high chance you job will simply be a lot easier in Julia.

I have recently been working with a REST API, something I don't do with either Python or Julia normally. I spent probably 10x as long time getting this to work in Python. It was not just a matter of not doing what I wanted, but also in not supporting well established conventions well as well as simply having far more complex APIs than the Julia equivalent.

This is something I frequently find. Julia APIs for doing the same thing as in Python will generally be much easier to work with.

Python APIs also tend to be very OOP oriented and stateful. Meaning there is a lot of mutating of hidden state. Julia APIs tend to show much more clearly what the data flow, is because they follow a more functional approach, where mutation of state is generally avoided. Although Julia is pragmatic. It isn't like working in Haskell.

NOTE: I am not saying Python is a bad language. It would usually be my second choice. I am just trying to say that there are REAL advantages to using Julia, which go far beyond mere performance. I never started using Julia due to performance but due to its expressiveness and clean APIs.

jimbokun• 6 years ago

Sounds like Innovator's Dilemma.

outlace2• 6 years ago

Julia as a whole still lags behind Python or Matlab (unsurprising given the age difference) but there are some packages in Julia that just steal the show compared to Python et al, such as the SciML packages and the probabilistic programming packages. I switched to Julia for Turing.jl when I was previously using Pyro. Much happier with Julia.

adamnemecek9• 6 years ago

The best thing about julia is the interop with essentially any language you can name. Want to call numpy?

using PyCall

np = pyimport("numpy")

res = np.fft.fft(rand(ComplexF64, 10))

The interop with matlab and cpp is similarly painless.

https://github.com/JuliaInterop/Cxx.jl

ed25519FUUU2• 6 years ago

Why interop with a language that already solves the problems? Just use that language.

cossatot• 6 years ago

I agree that this is great, but I think saying it's Julia's best attribute is underselling the language quite a bit. Personally I like how effectively it can replace those languages, at least for future projects.

ZephyrBlu• 6 years ago

Why is language interop not this simple for everything?

It seems insane to me that it's this easy in Julia, yet most other languages are completely incompatible without transpiling one into the other.

nextos2• 6 years ago

I love Julia, but I think comparing Pyro with Turing is pretty unfair.

Pyro can scale to pretty big datasets thanks to custom inference via guides. So you can do inference on pretty sophisticated models such as Deep Markov.

Whereas Turing is mostly for small or medium sized models. For learning purposes, for smaller models or for non-parametrics Turing might be a much better choice, though.

outlace2• 6 years ago

But isn’t the good scaling due to using variational inference rather than full MCMC? Turing has VI too.

datanecdote8• 6 years ago

The right benchmark is Stan

https://github.com/TuringLang/TuringExamples/pull/25

civilized• 6 years ago

What is going on here?

tgb• 6 years ago

Can the DifferentialEquations package actually solve quaternion equations correctly? Quaternions are non-commutative and I'd hazard to guess that some solver methods would assume commutativity at some point.

spacedome8• 6 years ago

My experience with various linear solvers (which a diffeq solver typicaly relies on) is that if they assume commutivity anywhere at all, which they often do, they almost definitely will not work for quaternions. Even if a derivation of the algorithm can be done with non-commutivity in mind, the implementation typically is not. Many NLA solvers are based on orthogonality transforms, which do not translate directly to quaternions, and even solvers which use only inner products and mat-vec multipication like BiCG do not really work as-is for quaternion matrices. Luckily dense linear solves with LU are fine! One can usually use the complex matrix expansion for quaternions and solve that instead without much difficulty though, and for computing eigenvalues this is perhaps even preferable, as it gives a canonical representation. I have not tried to use DifferentialEquations.jl for quaternion problems, so maybe they have figured some of it out, but it is non-trivial.

ChrisRackauckas2• 6 years ago

ODE solvers only use LU

LolWolf• 6 years ago

I would say it's probably worth converting your problem to its linear-algebraic representation and then using the solvers on that. They're quite fast there, and it's probably fairly easy to make a representation map and its inverse work well. (I will say that I don't usually deal with quaternions other than in a linear-algebraic form when doing some robotics stuff, so maybe this is more of a pain than warranted!)

spacedome8• 6 years ago

I found this approach to work well for linear systems, here is some rough code I used for the representation map (note the jmag/kmag functions are part of my implementation, not sure what the equivalent is for Quaternions.jl).

  function cmatrix(Q::AbstractVecOrMat{Quaternion{T}}) where {T}
      [complex.( real.(Q),  imag.(Q)) complex.( jmag.(Q), kmag.(Q));
       complex.(-jmag.(Q),  kmag.(Q)) complex.( real.(Q), -imag.(Q))]
  end

  function qmatrix(C::AbstractMatrix{Complex{T}}) where {T}
      n, m = size(C)
      quat.(C[1:n÷2, 1:m÷2], C[1:n÷2, m÷2+1:m])
  end

dragontamer15• 6 years ago

The important part of Julia is its programming model.

The implicitly parallel fork-join model is easy to program and incredibly general. And I'm glad to see a high-level language embrace it.

-------

I probably should note some other languages of this model: CUDA, OpenCL, ISPC, OpenMP, OpenACC. Most of these other languages are low-level, where you manage memory directly (and GPUs have very little memory per thread. So manual memory management is still hugely important)

But for speed of development, prototyping, and higher level reasons, a language like Julia that implements this "mindset" is going to be hugely important moving forward.

------

The fact that parallel fork-join scales from 2 CPU threads all the way up to thousands of GPU-threads... or CPU + SIMD (such as AVX512), is proof that this methodology is useful. I feel like people are sleeping on this model: its hugely useful for scaling on what I believe to be the computer of the future.

marmaduke25• 6 years ago

Classing for example ISPC as low level invalidates this comment for me; ISPC among others provides a great interface to SIMD model for CPUs that simply isn’t available in Julia.

dragontamer15• 6 years ago

ISPC is higher level than its peers, but its still new/delete based manual memory allocation. So in the great scheme of programming languages, its still rather low level (since you're manually handling memory).

Indeed: ISPC provides constructs to provide structure-of-arrays, and other low-level memory layout details. This is a good thing: these details have significant implications on the speed of your program.

Nonetheless, any language which wrangles with manual details of memory layout, or new/delete based memory allocation, is inevitably going to be classified as low level in my books.

ISPC among others provides a great interface to SIMD model for CPUs that simply isn’t available in Julia.

If Julia can compile into GPU-assembly (which is innately SIMD), I'm sure an AVX-based compile could work eventually.

They may have to target AVX512 (since most GPU-assembly requires per-thread exec-masks), but the general concept is being proven as Julia can now compile down into PTX or AMDGPU assembly.

Julia's compile down to GPU-assembly / SIMD code is not supported in the "general case", only in select circumstances. But that's still an incredible boon for a high-level language.

staticfloat2• 6 years ago

Julia's SIMD programming model is still very much a work in progress; I think we have a way to go in providing the kind of flexibility and control that languages such as ISPC, Halide, TVM, etc... provide.

That being said, packages such as SIMD.jl [0], and LoopVectorization.jl [1] are making fantastic progress, to the point that LoopVectorization forms the basis of a legitimate BLAS contender, in pure Julia [2]. It's not totally there yet, but it's close enough that real work is being done in LV at OpenBLAS-like speeds.

As an aside, I find it incredible that these kinds of extensions can be built in packages thanks to the fact that Julia's compiler is extensible enough to allow for direct manipulation of the LLVM intrinsics being emitted by user code.

[0] https://github.com/eschnett/SIMD.jl [1] https://github.com/chriselrod/LoopVectorization.jl [2] https://github.com/MasonProtter/Gaius.jl

amelius• 6 years ago

Could you be more precise about what do you mean by fork-join model? Is this similar to how in Go starting a thread is easy and waiting for it to finish and collecting results is easy as well?

dragontamer15• 6 years ago

I don't program in Go, so I can't speak to that.

The fork-join model generally starts off with one-thread, often called "The Single" or "The Master". Its where main() begins.

But somewhere along the line, you discover a portion of code that needs to be multithreaded. So you fork into many threads: maybe dozens of threads, or thousands in the case of SIMD or GPUs. This multithreaded portion is then "joined", that is, the "master" thread refuses to continue until all children are done executing.

Lets say there's a raytracer you are writing.

    main() {
      // In the "Single" thread
      Foo();
      Bar(); 

      fork(doRayCastingInParallel(), 5-million); // Spawns 5,000,000-threads, one for each ray
      // Implicitly wait for all 5-million threads to finish
      
      doSomethingElse(); 
    }

Now, raycasting has a bunch of things to do, but you can break it up into the same steps for all 5-million threads.

    doRayCastingInParallel(int myIdx){
      doTrigonometry(ray[myIdx]);
      findCollision(ray[myIdx]);
      outputColor[myIdx] = calculateColors(ray[myIdx]);
    }

So from both the "single" thread, as well as your "child" thread, it feels like you're writing single-threaded code. But in actuality, your "child" thread is a 5-million spawned copy, executing in gross parallelism.

The "Fork-Join" model assigns a different "myIdx" number to each thread. So Ray#500 knows to do things differently than Ray#68121.

But otherwise, they run through the same code.

---------------

The important bit here is how general this mindset is. Its commonly used for GPU-programming (CPU issues a GPU command to spawn millions of threads often one-per-pixel, or even thousands per pixel). Then the CPU waits for the GPU threads to finish, and then just carries on.

But ISPC proved that you can use this fork-join model on SIMD units like AVX512 or SSE. Julia and Python are showing off how you can use it in higher level languages. Etc. etc.

OpenMP further proves that fork-join works on normal CPU threads. Maybe there's some other CPU-threading languages (but OpenMP is the one I'm personally familiar with).

CyberDildonics• 6 years ago

Fork join parallelism is just one technique for using multiple cores and it is pretty ubiquitous. Most large arrays can be read by multiple threads at one time to let them all come up with part of the answer. I don't think this is specifically an advantage of julia.

gnufx7• 6 years ago

OpenMP, in particular, is not limited to fork-join, and you don't want to be so limited for efficient, scalable numerical systems. Not that you get large-scale parallelism just with OpenMP. A recent keynote of Jack Dongarra's covers replacing the decades-old use of fork-join for (or course) dense linear algebra: https://www.iwomp2020.org/wp-content/uploads/iwomp-2020-K1-D... It's significantly in the past, not the future, of large-scale computation of the sort Julia particularly targets. I don't know why Julia should be stuck with that, though. Parallelism isn't new to Lisp-y systems, of course.

dragontamer15• 6 years ago

I guess I still see Julia as a quick and dirty prototyping language akin to Python and some others. Clearly, Julia has ambitions for greater capabilities.

Apparently, Julia now supports some more complicated forms of parallelism: Async, @Spawn (aka: Tasks), and others. But @Thread based for loops are just easier to grok.

Overall, Julia is one of the few high-level languages that is explicitly adding in highly-threaded concepts like Fork-join, SIMD, or even GPUs to the language.

Yeah, some Python libraries extend these concepts to Python. But something like @Threads for ... end really demonstrates how the fork-join parallelism is a first-class member of the Julia language.

ed25519FUUU2• 6 years ago

Julia is an interesting language. I see that there's a lot of excitement for it, but most excitement seems to come from data scientists who are heavier on the engineer side. For almost all of the rest of the data scientists I know, Python seems "more than good enough".

Also to note, Julia has seen a rise over the last few years, but so has Python, its primary competitor in the data science field.

qaq2• 6 years ago

I am pretty excited about Julia potential for web apps

dnautics3• 6 years ago

I wouldn't be. I love julia, but it doesn't have a spectacular error-handling story. So if you have to start running a web server, and also have to worry about people issuing a DDOS or finding sneaky ways to cause your system to consume a ton of resources on a handful of threads, and lower availability, it's not going to get pretty.

Unless you mean compling julia or something like it to WASM and running it in the browser. That could get interesting, but julia is still "a bit too chonky" for that.

ku-man• 6 years ago

Nim is a great general-purpose language I have been using lately for my numeric and data heavy processing needs.

Julia's overenthusiastic posts here in HN make me wary of the language instead of curious.

MrMan• 6 years ago

Yes I like nim more than Julia but Julia has this big push behind it. If you put the same resources into nim it would be a more usable (not saying better) language.

smabie6• 6 years ago

It's only good enough for data scientists because they don't know any better.

For existing projects, fine, stick with Python. But Julia is strictly superior to Python in everyway, there is nothing that Python is better at than Julia. This is partially because Julia can call any Python library, but mostly because it's actually designed for data science and scientific computing.

bobajeff• 6 years ago

But Julia is strictly superior to Python in everyway

That is until you use the debugger.

dalke3• 6 years ago

"Everyway" seems like unneeded flamewar fuel. Here are a few things where it seems that Julia is not strictly superior to Python:

Julia doesn't run everywhere that Python does. Especially if you include all of the Python implementations, including MicroPython.

Last I checked, Julia's startup cost was high, making it the wrong choice for short-lived programs. Yes, people do scientific computing in short-lived programs.

Now, I don't know where Julia stands in this, but Python is used to teach people to program, including high school students and younger. By the time Python was 8 years old (as Julia is now), Python was being used in high school courses. Python's built-in "turtle" module exists as part of that education component - at one Python conference, an educator pointed out that it can be very hard to get anything installed at primary and secondary schools, so having a maintained "turtle" in the base installation was important.

I therefore suspect Julia is a worse teaching language than Python for high school level and below.

melling• 6 years ago

There’s a current Fall 2020 class at MIT that uses Julia.

https://computationalthinking.mit.edu/Fall20/

There’s a live video on ray tracing starting in about 20 minutes

https://youtu.be/MkkZb5V6HqM

threatofrain• 6 years ago

It's notable that the 3B1B guy is contributing to that class.

choeger• 6 years ago

Finally, Lisp wins ;).

masijo• 6 years ago

What do you mean?

ampdepolymerase• 6 years ago

Julia has a heavy Lisp heritage. If you want a clearer comparison, see Dylan. On the topic of Lisp, Julia's parser is written in a custom version of Scheme called femtolisp.

gnufx7• 6 years ago

Perhaps, as well as Dylan, it's worth referencing another Lisp system, T, that pioneered fast dynamic language implementations on the typical Unix workstation-type hardware of the time, and was of interest for research computing: https://en.wikipedia.org/wiki/T_(programming_language)

(T has some historical interest just as the original implementation language of the Yale Haskell compiler.)

nemoniac• 6 years ago

It's not finally. It's more like, here we go again.

Ideas from Lisp have been creeping into "mainstream" programming languages for decades. As the article points out, Common Lisp introduced multiple dispatch over 40 years ago and now it's finding its way into Julia. There's lots more in Lisp that can still find its way into a modern programming language.

I'm particularly interested in the inclusion of a LispSyntax for Julia that might allow Lisp macros to be written at the LispSyntax level that can then be used at the surface Julia level.

datanecdote8• 6 years ago

When I look at google trends or redmonk rankings, Julia appears stable, not accelerating.

DNF217• 6 years ago

I don't understand google trends. Julia's progress doesn't look like much there, but even python has had pretty modest progress there, which doesn't make sense.

aborsy• 6 years ago

Julia is better suited to numerical computation. Matlab is expensive and not really a language. Python is not designed for numerical computation and can be verbose.

The issue for Julia is, if you stay in Numpy and Scipy in Python, and can use JIT when applicable, you are basically using C. You can make it fast using C libraries and there is not whole lot of room for Julia to shine. Even with C, I had to be lately a bit careful to beat Numpy.

krastanov9• 6 years ago

I have quite the opposite experience. Numpy is terrible in terms of allocation overhead (even when you use the available, but limited, inplace operators and memory views). In Julia it is 𝚝̶𝚛̶𝚒̶𝚟̶𝚒̶𝚊̶𝚕̶ much easier to write allocation free code. And only so many operations are trivially broadcastable, after which numpy becomes very cumbersome and slow.

Numpy is a great piece of engineering, but its limitations are very noticeable when compared to Julia.

edit: not trivial, but much easier

spacedome8• 6 years ago

As much as I like Julia, I think "trivial to write allocation free code" is a bit of an overstatement. Depending on what you are doing, it can be difficult, for example iteratively calling any of the LinearAlgebra methods, since there is no interface for preallocating work arrays (doing the ccall on BLAS yourself is not a fun work-around). It is also not always clear why something is allocating, even with the debugging tools.

smabie6• 6 years ago

Numpy isn't actually very fast, especially if the data is small.

zemo• 6 years ago

so has anyone tried making games with this yet or no

eigenspace6• 6 years ago

Yes.

soVeryTired• 6 years ago

Anyone have thoughts on the ecosystem around Julia? Suppose you want to hook it into a database, or implement production-grade logging, or hook into e.g. Spark. Are those things do-able these days?

I've heard from some colleagues that Julia as a language is pretty solid these days, but all the machinery that you might need to take a system to production _aside_ from the business logic is a little lacking. I'd be interested to hear if others agree!

oxinabox2• 6 years ago

My employer (Invenia) runs Memento.jl (a logging package) in production, hooking in variously to SumoLogic and AWS Cloudwatch and from their into PagerDuty. I would say it is production grade logging. and it is integrated enough with standard lib logging that stuff logged using that also ends up at the right place.

I don't think it would actually be that hard to get the stdlib logging to work directly with that kind of system either. (Probably if we were starding today we might have built ontop of the stdlib logging, but Memento is a bit older than that, and a bit different in philosophy)

THere are a bunch of database drivers. We use LibPQ.jl in production. I hear good things also about OCDB.jl, and SQLite.jl also. and anything to do with data is really nice because of how interoperable all the data-frames like packges are. Everything just works together as long as the minimal API described by Tables.jl is implemented. (and everything implements that)

quixoticelixer-• 6 years ago

It depends. There are quite a lot of really good libraries for things like that but there are still a few important things missing.

diarrhea• 6 years ago

I don't have a CS background, so maybe that's how I'm missing the point here, but I don't see what is so supposed to be so special about Julia's multiple dispatch. In fact, reading more about it and knowing Python, single dispatch/polymorphism feels more natural to me. This would allow a `plot` function in Python, originally written for the float data type, to also work for float-like (quacks like a duck) data types, like `Decimal`. I struggle to see what about Julia improves on this situation or makes it conceptually different.

Lastly, the article mentions that `plot` also works for uncertainty-carrying floats, because the `Measurements` package has implemented "a simple recipe" for this case. But doesn't this mean very tight coupling? The `Measurements` author very specifically (if I understand this right) implemented a `plot` functionality. For the end user, this allows things to just work, which is great. But under the hood, it seems this depends on package authors having to be aware of all possible use cases for their library code.

pdeffebach2• 6 years ago

This would allow a `plot` function in Python, originally written for the float data type, to also work for float-like (quacks like a duck) data types, like `Decimal`.

This might come with sacrificed performance. If you want a different implementation for a different data type to get the best performance, writing one method makes that hard.

The `Measurements` author very specifically (if I understand this right) implemented a `plot` functionality.

This is a good point. But in that example, note that `Measurements` also works with all of differential equations, and they didn't implement any differential equations specific code, unlike as you pointed out with `plot`. The fact that uncertainty propagates through a differential equation solver is pretty impressive, imo.

jschwartzi3• 6 years ago

Yeah as I was reading this it occurred to me that a startling number of lab reports I wrote as an undergrad would have been much easier to do in Julia. We normally used Excel for the calculations and had to check all of our propagation of errors by hand.

smabie6• 6 years ago

Multiple dispatch is nice because it makes extending library (or any) code very trivial.

The seamless way in which Julia libraries can be mixed and matched and used together is a testament to this. Python on the otherhand, each library is its own little world and cannot be used in novel or unexpected ways.

Moreover, the unperformant nature of Python means that you must use libraries in very cookie cutter ways or else performance falls off a cliff.

ddragon4• 6 years ago

As the name implies, single dispatch is just a special case of multiple dispatch. Everything that can be done with single dispatch works exactly the same (arg1.f(arg2...) is just f(arg1, arg2...) in Julia), so there is no loss in expressivity. The only conceptual difference in multiple dispatch is that arg1 is not considered special, which makes sense for a scientific language as for example in 1 + 5 the operator '+' isn't really owned by the "object" 1, it's a property of the whole formula (the combination of the operator itself and all operands).

And the consequence in terms of programming is exactly that it that it shifts the responsibility of handling interoperability to whoever creates a new type. For example if I create MyType and want a method SomeoneType + MyType to work, I don't need to change the '+' implementation on SomeoneType for that to work (for example making a PR on his library), I only define methods with the type I just created. Which is why people say Julia ecosystem compose a lot, the creator of SomeoneType can just focus on what he wants and possibly never even know about MyType, MyType will extend it with whatever I want without having to re-implement stuff that SomeoneType already implemented (only MyType stuff and the intersection between libraries, defined by methods that use MyType and SomeoneType), and the final user can just import all stuff he wants and have a library that looks like a monolith but is actually many smaller libraries working together this way.

shepik2• 6 years ago

The deal with multiple dispatch, as I understand it, is that instead of obj->somemethod, you define function named somemethod, which is defined for obj. Maybe some other code calls it.

You can then define somemethod for other data types, without touching the original definition, and that makes your new definition available to the other code that used the original somemethod. It is a unique feature of Julia (at least unique in a sense that it is absent from mainstream languages)

jabl• 6 years ago

The thing that distinguishes multiple dispatch from single is that you can dispatch based on the types of all arguments to the method, not just one. E.g. you can define

function somemethod(x::Int, y::Int)

function somemethod(x::Int, y::Float64)

function somemethod(x::Float64, y::Float64)

Multiple dispatch is available at least in Common LISP, though I guess that's not considered particularly mainstream.

StefanKarpinski4• 6 years ago

The core problem with class-based object orientation is that methods go inside of the type instead of being added externally. That means everyone has to agree on what methods can be called on a class or they have to subtype it, which sounds harmless, but is actually a big problem when what you really wanted to do was just define a new method for an existing type. My best attempt at explaining: https://www.youtube.com/watch?v=kc9HwsxE1OY

There's also the issue that one sometimes needs to specialize generic operations in generic algorithms on something other than the receiver—sometimes even on more than one of the arguments. Single dispatch forces you to use something slow and awkward like double dispatch in cases like this. And that's assuming the person who wrote the generic code anticipates the need for specialization! If they don't allow for it, then you're just stuck. With multiple dispatch, you can just define the method you need the specialization for and you're done.

leephillips5• 6 years ago

A couple of the other replies might have answered this for you already. You are correct that the recipe is specific to the Plots package. But consider: once written, it works not only for that specific plot function, but many others in the package as well, for example scatter. Also, I have written these recipes for my own data types, and they are incredibly easy to create. The recipe informs the functions in Plots how to handle your datatpye, so you can just pass it in as an argument. The thing is that I’ve never even looked at the code in the Plots package. With Julia you can use functions on combinations of your own custom datatypes to do new things, without looking at the code for the functions. Often nothing like the Plots recipes are required; but here the recipe lets you specify how you want your datatype to be visualized.

gnufx7• 6 years ago

Apart from CS and how software construction works with these things in practice, I reckon multiple dispatch is natural. At least it is to someone with a physics background, which is the context in which I encountered it long ago. I'm used to thinking essentially functionally and in terms of operation->arguments/objects (or verb->subjects), not something with the order and asymmetry of, say, object.operation(object). I wouldn't expect an operation to be tied just to one of the operands. I've seen the result of people trying to explain to scientists, say, Java-like "OO" as if it was somehow mirroring the sort of things they work on.

munificent• 6 years ago

This would allow a `plot` function in Python, originally written for the float data type, to also work for float-like (quacks like a duck) data types, like `Decimal`.

So let's say you do that. You define your own new number-like type, say Complex. You pass that in to plot(n).

Somewhere in the body of plot(), though, it turns out there's some code like:

    # Flip to put origin at bottom left.
    window_height = 400
    y = window_height - n

So now plot() tries to invoke "-" with an int on the left and your complex number on the right. It passes your complex number to the int class's minus operator, which has no idea about your type and barfs.

Python has a hacky workaround for this specific case where the right operand can implement __rsub__(), but that hacky workaround exists specifically because Python doesn't have multiple dispatch.

If it supported multiple dispatch natively, you'd just define an operator - that took a number on the left and a complex on the right, plot() would call it, and you'd be good.

leephillips5• 6 years ago

Wow, nice example. Made possible also because arithmetic operators in Julia are functions, and you can extend them to work on any data types. (Operators like "+" have hundreds of methods.)

musingsole3• 6 years ago

__rsub__ isn't a hacky workaround. Magic methods are a fundamental part of python's object model. If you think it's hacky, I think you don't grok python.

If it supported multiple dispatch natively, you'd just define an operator - that took a number on the left and a complex on the right, plot() would call it, and you'd be good.

This doesn't come across as a win to me.

socialdemocrat3• 6 years ago

I wrote two articles which may clarify this better. One is about creating custom temperature units in Julia and Python. It shows how multiple dispatch gives an advantage over single dispatch: https://medium.com/@Jernfrost/defining-custom-units-in-julia...

This story is more like a general intro to Julia, but it has an example with Knights, Pikeman and Archers fighting each other (sort of rock, paper, scissors game), which also shows the utility of multiple dispatch.

https://levelup.gitconnected.com/knights-pikemen-archers-and...

But to give a quick idea here. Imagine writing functions for intersecting two geometric shapes. The algorithm for intersecting a circle and square is entirely different from intersecting a polygon and a line segment. The specific algorithm needed will depend on BOTH shapes not just one. Python can only dispatch on one of the shapes, not both.

So in Julia I could write a different function implementation like this:

    intersect(c::Circle, r::Rectangle)
    intersect(c1::Circle, c2::Circle)
    intersect(r1::Rectangle, r2::Rectangle)

and so on.

musingsole3• 6 years ago

I appreciate your first article demonstrating the differences between Python's single dispatch and Julia's multiple dispatch, but your python example suffers from a lack of a child-aware parent class, Temperature, that could resolve the complaints raised. You're building inherently coupled classes in a decoupled way and complaining that they don't mix well.

musingsole3• 6 years ago

As the other answers note, multiple dispatch is largely a performance improvement. When writing Python, performance has usually been sidelined as a priority in the first place (within some constraints).

Personally, I hate this presentation. Multiple dispatch (to me) is cognitively heavier and not what I would default to. If it's a performance gain and I need performance, then sure. But too often people hold it up as a virtue because the need for speed is assumed.

amkkma5• 6 years ago

What? I used to write python, and to me, MD is first and foremost a conceptual improvement. Makes writing code so much sweeter, more expressive and sensical.

It also heavily improves composability.

It's LESS performant if not done carefully. Certainly FastAI, Matt rocklin etc didn't reimplement a subset in python just to get slower code

See https://youtu.be/kc9HwsxE1OY

FranzFerdiNaN2• 6 years ago

Julia is a wonderfully designed language and I fully anticipate making it my main language in a few years. Right now I will stick with R though, because R’s ecosystem is simply unparalleled right now. And for someone who is not terrible interested in programming, except as a way to get things done, that is what matters most.

But i really think that in a few years time, when Julia’s ecosystem has had more time to grow and develop it can rival R.

eigenspace6• 6 years ago

And for someone who is not terrible interested in programming, except as a way to get things done, that is what matters most.

For what it's worth, I found that taking the plunge into julia is what made me love programming.

I'm constantly amazed by how easy it is to whip something up myself that before I would have relied on a built-in routine in another language. Doing this made me a better programmer and more capable of doing the things that 'matter most' as well.

Plus, whenever I whip something up myself, I try to share it with the community either as it's own package or as a PR to an existing package, so I get to feel involved in the progress as we get to the sort of ecosystem you would find acceptable.

dunefox3• 6 years ago

Why wait? https://github.com/JuliaInterop/RCall.jl

unnouinceput• 6 years ago

Searching for Julia related work on Upwork resulted in only 3 jobs. One of them was actually to port an existing application from Julia to C++

jrevels• 6 years ago

I think one of Julia's greatest indicators of long-term success is the variety of commercial users/companies from a diverse pool of technical domains/industries that are all excited, willing, and capable of contributing back to the ecosystem.

We had a BoF at this year's JuliaCon revolving around this topic [1] and are now planning the first Annual Industry Julia Users Contributhon as a result.

I especially think that well-configured Julia + K8s setups have the capacity to really tighten exploratory data science <-> operational data engineering feedback loops in industrial settings in a way that is much more ergonomic, generically useful, and portable/extensible than using pre-baked frameworks to achieve something similar. Julia-centric tooling for coarse-grained workflow orchestration, experiment tracking, data provenance, etc. would be nice, though I also think existing generic tools in this vein (e.g. Argo) could probably compose well too :)

A few different companies have nice in-house implementations of these kinds of setups, and Julia Computing is building a nice looking commercial product suite in this vein that I look forward to exploring more in the future (especially JuliaHub and JuliaRun).

[1] https://julialang.org/blog/2020/09/juliacon-2020-open-source...

sida• 6 years ago

Honestly, I just wish that this was 0-indexed. 1-indexing annoys me enough that I haven't really started playing with Julia.

throwaway889900• 6 years ago

There's nothing preventing you from using a 0-base, it's just extra work to implement. You can even use the fabled 2-base index! https://docs.julialang.org/en/v1/devdocs/offset-arrays/

henearkr2• 6 years ago

For people complaining about 1-indexing, it is precisely because they wish what they feel the "natural" way to count would come without overhead.

So it's this "extra work" that is the problem.

It would be nice to have it as an environment variable or a runtime option. Then what about portability issues...

So let's just fork Julia and call it JuliB with 0-indexing =)

socialdemocrat3• 6 years ago

I don't get why people care about this. How often does that hit you in normal code? It never bothered me in Lua, and certainly not in Julia. For me I just do a context switch. I know when I am in Julia I have to think about things like in my mathematics books. Just like you index a matrix.

When I am in other languages like C/C++ I tell myself that I working with memory addresses. For memory addresses 0-index makes more sense. For tables, matrices etc I honestly think 1-based indexing makes more sense.

Only time I dislike 1-based indexing in Julia is when I write code which is strongly related to how memory works. Like when I was implementing a CPU simulator and assembler.

henearkr2• 6 years ago

It depends on which kind of maths you refer to.

After studying ordinal numbers, I feel like the normal way to start counting is from 0 (or the "empty set" ordinal).

This is also how you prove something by transfinite induction, you need to start by 0.

I wish I could easily recompile Julia so that it is 0-indexed. But then what about all the libraries...

FranzFerdiNaN2• 6 years ago

I wished python was 1-indexed. I can't count the number of times I made an error because somehow programming languages count from 0, which is insane. I also keep having to do dumb things like len(x)-1, which also is dumb.

patal2• 6 years ago

It's mostly about habit. Apart from that, I really enjoy this venture into the history of 0-based vs. 1-based indexing: http://exple.tive.org/blarg/2013/10/22/citation-needed/

the technical reason we started counting arrays at zero is that in the mid-1960’s, you could shave a few cycles off of a program’s compilation time on an IBM 7094. The social reason is that we had to save every cycle we could, because if the job didn’t finish fast it might not finish at all and you never know when you’re getting bumped off the hardware because the President of IBM just called and fuck your thesis, it’s yacht-racing time.

ahurmazda• 6 years ago

Pet curiosity ... if the inventors would humour me.

What was the thinking behind adopting the `end` notation for marking the end of blocks. I know that certain family of PLs (Erlang, Ruby) use them. But the dominant flavor is the `{}` syntax (c/c++/scala/rust etc)

Was it an explicit choice or more based on your past familiarity with other languages?

newen• 6 years ago

It’s from Matlab. That’s really it. Well, and probably {} are perfectly good characters that shouldn’t be wasted on code blocks.

patal2• 6 years ago

So it's from Fortran ;)

eigenspace6• 6 years ago

The reason is that they want to reserve the curly braces for other uses and the language devs call using `{}` to delimit code a 'waste of valuable ascii characters'.

Julia currently uses {} mostly for type systemy things like parametric types. When I write Foo{T}, this says that T is a parameter in the type Foo.

E.g. a vector of Float64s in julia is an Array{Float64, 1} (1 means one dimensional) whereas a matrix of vectors of complex Ints is an Array{Array{Complex{Int}, 1}, 2}.

lenkite• 6 years ago

Please allow Julia tooling to easily compile to a native binary/dynlib/dll that can be deployed on both desktop and mobile OS'es.

Right now, it appears like a niche interpreted language for numeric geeks only.

vsskanth• 6 years ago

https://github.com/JuliaLang/PackageCompiler.jl

Note that it doesn't do slim binaries yet for embedded. Don't know if that's in the roadmap.

edsac_xyzw2• 6 years ago

Matlab and its Simulink extension, which is widely used for designing control system has a feature for generating C code that can be deployed without Matlab runtime. Someone with knowledge of code generation and compilers could take this Matlab feature as an inspiration and implement a C code generator for Julia functions.

Right now, it appears like a niche interpreted language for numeric geeks only.

Yes, it was designed for numerical and scientific computing. In Julia, you can at least prototype the numerical algorithm before implementing in C++ or Fortran.

The Accelerating Adoption of Julia

Related Stories