[anon_342njlkesr]

Yeah, the language design of julia is brilliant (multiple dispatch, typing, llvm use, zero-cost abstractions, @code_native to see why your code is slow).

This allows you to write fast code in julia, which is impossible in python (you can call into very fast C/Fortran libraries with nice bindings, though).

On the other hand, I really hate the syntax. One-based array indexing (ok, minor), blocks ending with "end", and most importantly unicode support.

Really, who thought that it was a good idea to allow symbol names that are unreachable on a standard US keyboard? WTF? This makes it supremely inconvenient to use libraries that happen to export symbols with crazy names. If you must, specify a name mangling scheme and let people who want to see crazy symbols use an IDE. Seriously, am I supposed to use a hex-editor when auditing julia code?

I totally agree with the author that package discovery and uniformity are a big problem. Indeed, this is even moving in the wrong direction: More and more functionality is removed from Base and put into external packages. I would prefer a more "batteries included" style, with uniform quality and documentation for standard functionality (splitting into different namespaces is good, though), python-style.

Second non-cosmetic problem is that the language documentation is atrocious, both from a completeness and pedagogical viewpoint. Pyhton is again the ideal to aspire to.

But the point of the article stands: It is easy to write fast julia code, and the Julia (non-C/C++) parts of the Julia core form a nice tutorial for how "good" julia code looks like. If a function is not well-documented, look at the source code. In python, you quickly run into the C-wall (function is really implemented in C and the way the wrappers work is really non-uniform); in julia this is more rare, and the wrappers tend to be much easier to pierce (ok, julia does a ccall, figure out the code of the target; the wrappers are human-generated and readable and don't come out of a complex build environment).

But yeah, you shouldn't use julia for systems programming until a good standard way for unmanaged code has been fixed, if ever (mixing types that are garbage-collected and types that are programmer-memory-managed, you want garbage-collected types for performance-irrelevant parts and programmer-managed types whenever precise memory alignment matters for your performance). Oh, and the nullpointer support sucks big time.

My personal hope is that the python->julia interface improves. Then python users will be able to profit from fast, easily developed julia packages.

[jernfrost]

I greatly prefer Julia syntax. `end` makes the code blocks stand out more easily than }. I find it easier to see the indentation at a glance than when just dealing with a single thin character.

Also I like that Julia prefers shorts words over special characters. C/C++ use far too many special characters.

That might run counter to my delight at unicode support. I think it is quite nice to be able to write mathematical code using the same symbols as used in mathematics. I use the Julia REPL to write this where you got latex completions to get unicode characters.

"Second non-cosmetic problem is that the language documentation is atrocious, both from a completeness and pedagogical viewpoint. Pyhton is again the ideal to aspire to."

I could not disagree more. Here is an account of Julia vs Python from mostly a pedagogical point of view: https://medium.com/@Jernfrost/python-vs-julia-observations-e...

A few points. Documentation is often easier to read. E.g. look at the example of the `print` function.

Function usually have more sensible names in Julia and you don't have to guess which package they are hidden in for common things such as working with strings, paths and arrays. Part of this is due to Julia multiple dispatch which allows reusing the same function name for related functionality, while python is forced to invent unique function names too often. Even when it doesn't make sense.

I'd say Julia adheres to the Python zen of least surprise. Checking if a collection is empty, can be done with `isempty()` which is similar to a number of other languages. Python in contrast treats empty lists as boolean objects which are false when empty. How is that obvious?

[anon_342njlkesr]

Re unicode:

When writing latex, you don't want to encounter unicode greek sigma. You want \sigma, as 6 7bit-ascii chars. Same in julia; sure, define a display mode that translates certain things into unicode for people like you, but keep compatibility with code-editors/people/tools who do not understand unicode. In short: I want to it to be possible to use a dumb text-editor, not an IDE/word-processor. (ok, the text editor will need to understand UTF8, because unicode string literals are really important; but please never go beyond a small white-listed subset of 7bit-ascii for language tokens).

[jernfrost]

LuaTex which is displacing Latex is doing just that, increasingly using unicode directly. I’ve never used a plain editor on my Mac which DIDN’T handle unicode. In fact I use a plain text editor to write julia code whith unicode symbols. Anyway it is a tiny portion of the code and the Julia public API never force you to use unocode. You can always chose a non-unicode variant of the API.

Not using UTF8 in this day and age is just begging for problems.

At least on my mac you got OS wide tools for working with unicode.

[ChrisRackauckas]

The convention in Julia is to not have unicode in user-facing APIs. That way you're not forcing unicode on anyone. All of the big libraries and the Base module do this. So you can use unicode for your variables to match your paper if you want, but no library (that I know of) is going to force you to have unicode support in your terminal.

[mkborregaard]

Just a response for a few comments, since you talk with confidence but could maybe do with a closer look: 1. You end with `end` in julia. 2. You can use indexing with any base, not just 1 - no performance penalty. 3. The julia repl comes with latex completions making it very easy to just type e.g. \sigma and get the sigma sign. 4. The package system is moving both directions - functionality is split into modules for interoperability, but are gathered in batteries-included metapackages again. Like typing `using DifferentialEquations` will load all 60 small DifferentialEquations packages (centrally documented), but you can easily plugin alternatives if you like.

[anon_342njlkesr]

Re 2: Yes, but most of the language is geared towards 1-based indexing, e.g. ranges like a:b being inclusive at the right. Hence, using a zero-based variant of array makes only sense if your code really really profits from zero-indexing.

Btw, the question should not be "is zero-based slower"; I know that julia has zero-cost abstractions. The question is whether is is faster, because of the avoided decrement instructions for the underlying pointer arithmetic: say, M=Matrix{Int64}(4,N), then @inbounds x=M[i,j] corresponds to x=unsafe_load(pointer(M), i + (j-1)*4). And the internal C code needs an extra decrement on i, because array data pointers use the C convention of pointing to the first element.

Re 4: This is a problem with discoverability and dependencies. Say, my code needs a heap-queue.

Sure, heaps exist, e.g. in datastructures.jl. But there is no canonical documentation / default choice in the base language, like e.g. heapq in python.

And if you want to figure out how to use custom orderings for your heap you end up reading the source code of all 2-3 heap implementations in datastructures.jl (which use different incompatible APIs), because the documentation fails at providing examples. Older julia versions came with heaps included.

Re 3: The REPL is not everything. By all means, define a global name mangling scheme that (with default options) symbol-names should be latex-displayed in the REPL or ijulia. I mean, when using a mono-spaced font you don't want to see a greek sigma in latex either! You want the code, i.e. \sigma, and you want someone (not yourself) to write a word-processor that inline-displays weird characters for your grandma.

Don't understand me wrong, I like julia; it is just that every single "mostly inconsequential" / matter-of-taste design decision pisses me off, whereas the really important parts are awesome.

Re 1: Maybe I haven't written enough fortran in my life, but both python-significant-whitespace and C/java-style curly braces make a lot of sense and are very easy to parse and highlight (for text editors). But sure, I understand that this is matter of taste, and very cosmetic.

Bonus problem: By default, multidimensional arrays access is such that the first index is fast for iterations. This is different from C layout, and means that A[i,j] corresponds to A[j][i] if you switch out Matrix and Vector{Vector}. I know that fortran did it that way, and I think this was a mistake in fortran already.

[ChrisRackauckas]

>Sure, heaps exist, e.g. in datastructures.jl. But there is no canonical documentation / default choice in the base language, like e.g. heapq in python. And if you want to figure out how to use custom orderings for your heap you end up reading the source code of all 2-3 heap implementations in datastructures.jl (which use different incompatible APIs), because the documentation fails at providing examples. Older julia versions came with heaps included.

If you watch Stefan's 1.0 talk (https://www.youtube.com/watch?v=qHpaztMu_Uw) you'll see that one of the reasons we want 1.0 out is so that way this kind of non-breaking work can get priority. 1.0 is about doing all of the breaking changes to the language. 1.x releases, and package work, are about actually using it. It's known that DataStructures.jl needs work which is why it's even mentioned in the talk as a 1.x improvement goal.