1) Makes logical sense, but from the point of view of the casual programmer or beginner it is an annoyance. To me it is just one more reason why you want everything to be an expression just like OCaml, Haskell, LISP, Ruby etc. Usually these languages solves a = 5 by requiring if statement to take boolean expressions.

2) As remarked to another commenter the purist in me would object to len(a) as it is a O(N) operation for linked lists or UTF8 strings.

4) I was arguing from the point of familiarity and least surprise. isempy() works in many languages and $var style interpolation works in bash scripts and perl. People should thus already be used to it. It is practical since Julia is intended to work with shell scripting, and you can then use the same convention in many similar cases. String manipulation is so common in scripting that you want a script language to make it easy.

3) & 5) I didn’t write this from an engineering point of view, if I would have talked more about the python GIL lock, optimization challenges etc . Rather I looked at this from the point of view of a beginner or casual user. It was not meant to bash python. However Python is often used as a measuring stick for programming ease of use. If Julia can get away with a favorable comparison to Python I think that speaks in favor for anybody considering Julia.

Not only does it give you good performance but it is also quite a nice language to use for beginners.

I say this knowing that of course Python has a profound edge in available, packages, size of community etc. But we all got to start somewhere. When I was advocating Python to everybody 15 years ago it was in quite a similar situation as Julia today.

Written by

Geek dad, living in Oslo, Norway with passion for UX, Julia programming, science, teaching, reading and writing.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store