Julia for Python programmers

One of my clients is writing software in Julia so I’m picking up the language. I looked at Julia briefly when it first came out but haven’t used it for work. My memory of the language was that it was almost a dialect of Python. Now that I’m looking at it a little closer, I can see more differences, though the most basic language syntax is more like Python than any other language I’m familiar with.

Here are a few scattered notes on Julia, especially on how it differs from Python.

  • Array indices in Julia start from 1, like Fortran and R, and unlike any recent language that I know of.
  • Like Python and many other scripting languages, Julia uses # for one-line comments. It also adds #= and =# for multi-line comments, like /* and */ in C.
  • By convention, names of functions that modify their first argument end in !. This is not enforced.
  • Blocks are indented as in Python, but there is no colon at the end of the first line, and there must be an end statement to close the block.
  • Julia uses elseif as in Perl, not elif as in Python [1].
  • Julia uses square brackets to declare a dictionary. Keys and values are separated with =>, as in Perl, rather than with colons, as in Python.
  • Julia, like Python 3, returns 2.5 when given 5/2. Julia has a // division operator, but it returns a rational number rather than an integer.
  • The number 3 + 4i would be written 3 + 4im in Julia and 3 + 4j in Python.
  • Strings are contained in double quotes and characters in single quotes, as in C. Python does not distinguish between characters and strings, and uses single and double quotes interchangeably.
  • Julia uses function to define a function, similar to JavaScript and R, where Python uses def.
  • You can access the last element of an array with end, not with -1 as in Perl and Python.

* * *

[1] Actually, Perl uses elsif, as pointed out in the comments below. I can’t remember when to use else if, elseif, elsif, and elif.

16 thoughts on “Julia for Python programmers

  1. It borrows a lot from the (in my opinion quite elegant) Matlab syntax:
    – Defining functions with “function” and “end”
    – Straight brackets for matrices
    – 1-based counting

    I’m in a love-hate relationship with Matlab, so I might just be projecting that on everything. Still I think they took the nice parts of Matlab and coupled it with the nice parts of Python.

  2. Thanks for the writeup.

    Some very small comments:

    1. Multiline comments are delimited by #= and =#.

    2. Integer division is div(a, b) or a ÷ b.

    3. Lua also uses 1-based indexing, although 1993 might not qualify as “recent”.

  3. Arrays start at 1? So any code – any convenience function or useful snippet Ive collected over the years – I’d move from another language will need rewriting and extensive debugging before it works again. No thanks.

  4. Aslak: The choice of 0 vs 1 based indexing isn’t that big a deal in itself. There are pros and cons to both. It’s sort of like driving on the left or right side of the road. Either is fine, but switching is a likely cause of accidents.

  5. Yes, and Julia is designed for scientific computing and data science and many people in those fields will be familiar with R and Matlab.

  6. And one of the most notable difference from Python / Matlab / R – is the type system, which is pretty neat in Julia and tuned specifically for scientific computing.

  7. When I first began programming in 70s, the norm was 1-based indices like with Fortran and early BASICs. This seemed normal, but then along came C, with 0-based arrays. At first seemed odd to start with 0 but when combined with the use of asymmetrical bounds, lots of -1’s and +1’s started magically disappearing from my code, along with most fence-post errors. It’s hard to imagine going back, really. Here’s Djikstra’s argument for 0-based arrays, which naturally makes the case for asymmetrical bounds as well.


    I can see wanting 1-based arrays when coding mathematical formulas, because that’s the norm in that realm. When I’m faced with that problem, I stick to the math way of indexing by just ignoring the a[0] element.

  8. Julia is not Python with a slightly different syntax and learning it this way by translating Python syntax into Julia via a set of rules like yours will lead to a very biased and wrong view of what Julia is. Also julia took inspiration from a lot of languages and Python is definitely nost the main one: Common Lisp & R are more important.

    The syntax is only superficially like Python, e.g. whitespace is NOT significant in Julia and that’s a GOOD thing. It’s in fact closer to Ruby: replace def with function in Ruby and you have a Julia function.

  9. As a 72-year-old math student and long-time professional Matlab programmer (who began with FORTRAN and BASIC) indexing from 1 is OK by me. Last year I benchmarked Julia (0.2.0) against several other languages (and several CPUs, except for Julia) …


    … but I haven’t heard much about Julia since … until John’s post. Always interested in Matlab alternatives. Can anyone comment on the uptake of Julia?

  10. @NoelZinn you should check out newer versions of Julia. I coded up your pseudo code in Julia 0.4 and Matlab 2015a (really want to try the 2015b to see how the improved jit might help) and I get that the Julia code is around 2.5x faster vs your older finding of being 4x slower. Not that this matters, but it seems they have been making some progress.

  11. I read Dijkstra’s reasoning as supplied by Jack Kennedy above. Here’s the money quote:

    “When dealing with a sequence of length N, the elements of which we wish to distinguish by subscript, the next vexing question is what subscript value to assign to its starting element. Adhering to convention a) yields, when starting with subscript 1, the subscript range 1 ≤ i < N+1; starting with 0, however, gives the nicer range 0 ≤ i < N. So let us let our ordinals start at zero: an element's ordinal (subscript) equals the number of elements preceding it in the sequence. And the moral of the story is that we had better regard —after all those centuries!— zero as a most natural number."

    Death, taxes and either +1's or -1's. It is inevitable. I certainly don't find Djikstra's reasoning all that convincing. If you want a vector of length n=10, you need an index to run from 0 to n-1. Working with vectors as vectors, say in three space, the 0 index in very inconvenient. Working with vectors in Lorentzian 4-space, the 0 index is fine (but so is an index 1 through 4 with either 1 or 4 being the time variable).

Leave a Reply

Your email address will not be published. Required fields are marked *