DNF2

You code in anger? How does that work:D?

Anyway, Julia is my preferred language, and it has the depth to teach you widely useful concepts. For example, I'm now learning C++, and my Julia experience has been very valuable.

Python, of course, is the safe, mainstream choice. (If you want her to become a weirdo or outcast, you might of course consider C or Fortran;)

I have never noticed them being bad for performance. Are you really sure?

"Any other PL"? Really? Well, that is news to me:)

Anyway, the answer to your question is very simple: Because it's difficult, and a lot of work. Not because they can't be bothered, as your question seems to imply.

I think the point is that one wants to write code that is similar to regular non-performance sensitive python code, with classes and everything, and still have it be fast.

You mean the fact that someone submitted this on Hacker News? Yeah, sure, that was quite pointless. Submitting code to Benchmarks Game was fine, though.

I'd say most of those optimizations are not needed (`@inline`, `@ntuple`, `@inbounds` can also often be dropped).

Vectorization, in the sense of using `.+` etc, does not provide any speedup in Julia, it is only for notational convenience, and is at best the same speed as a loop, often slower.

Isn't this mainly because the first run includes compilation? The compiled code should use little memory, if correctly written.

The Benchmarks Game isn't some Julia project, and it is unreasonable to blame the presentation of results on some 'chip on the shoulder' of Julia the language.

The Benchmarks Game is a project that dates back to at least 2002 (https://benchmarksgame-team.pages.debian.net/benchmarksgame/...), a decade before Julia was announced, collects code from many different languages, and lets you filter the results depending on what you are interested in. Go to the website, click on Python, and when selecting the other language, Python's results are in bold.

Why should Julia users be criticized for contributing code to a website dedicated to performance benchmarks, but it's ok for Python/Fortran/C/Javascript users to contribute? And why should this contribution from some individual count as evidence of some 'shoulder chip' for the wider language community?

(BTW, all benchmarks in all languages appear to be running on 4 cores, so it's not that weird for Julia to set NUM_THREADS to 4.)

Yes, but not from C++, but from Julia source code. Or what are you referring to?

What is a "fixed-point float"? That sounds like a contradiction.

And what sort of transfer function are you referring to?

The ;; is similar to the space, in that it separates elements in the second dimension. But they are not quite equivalent, because you cannot write [1;;2;3;;4]. With semicolons you have to start with the innermost dimension and work outwards. The space notation is there so that you can write the array in row-order, since that is very common.

What? I mean, it's a solution to an unnecessary problem caused by indentation being significant.

The problem wouldn't exist if whitespace wasn't significant, which was an unfortunate design choice. So it's a solution to an unnecessary problem.

If you say so. I've never heard of either of those, and have only the vaguest idea of what a 'formatter' might be. Is it not a solution to an unnecessary problem? And how can a formatter fix a lost indentation that changes the meaning of the code?

I do know for sure that my colleague will never use this, even if I might.

Fortunately, this isn't an issue in the languages I use most of the time.

(Another problem that's bothering me almost as much is that without brackets or `end` statements, the code looks assymmetrical - unbalanced and awkward, as if it's trailing off, having forgotten its purpose.)

My problem has been that I sometimes lose indentation, by accident, and this can break or, worse, alter the behavior. It is also a nuisance when I want to copy-paste code from somewhere else, and it doesn't go smoothly.

Once I needed to incorporate code from a colleague who used 2 spaces for indentation. That was a nightmare.

To address the specific examples: [1,2,3,4] is literal vector creation, and also "," is just the regular way you create a list of inputs to a function. [1;2;3;4] is concatenation along the first dimension, so it must be the same as [1,2,3,4].

[1,2,,3,4] has no meaning, because repeated "," hasn't been given any syntactical meaning. But maybe that would have been a good idea?

[1,2;3,4] mixes literal vector syntax and vertical concatenation. The only reasonable interpretation would be that it's the same as [1;2;3;4], so maybe it could have been allowed, but ";" is supposed to concatenate arrays, with a special case for scalars (0-dimensional arrays), it's not clear to me what would be concatenated in [1,2;3,4].

[1 2; 3 4] on the other hand, concatenates two row vectors vertically, so this has a clear meaning. It can't be equivalent to [1;2;;3;4], since that has 1 and 2 lying along a column not a row.

A 3D tensor can't be [1 2;3 4;;5 6;7 8], since it only has ";;" while concatenation along the 3rd dimension must be ";;;". The notation [1 2;3 4;;; 5 6;7 8] works for this, but mixing whitespace notation and ";" notation is confusing.

So, clearly this is all a bit complicated, but it is a solution to a somewhat complicated problem, where you both need to allow new, consistent, notation, while simultaneously keeping the historical notation, which is in fact better in the most common (lower-dimensional) cases.

The semicolon use is actually completely consistent, ";", ";;", ";;;" etc. do indeed refer to incrementation of the corresponding dimension. Try [1;2;3], then [1;2;3 ;; 4;5;6] and then [1;2;3 ;; 4;5;6 ;;; 7;8;9;; 10;11;12]

The confusion arises because "," and whitespace also have overlapping meanings in array notation. "," is used for regular vector creation, and whitespace for concatenation in the second dimension. The coexistence of those two different notations is a bit uneasy, but I doubt that "," and whitespace will be deprecated, since they are so entrenched and familiar. And for 1D and 2D arrays (which probably make up >99% of all literal array use) it's also more elegant and clean.

Maybe this will help: "," separators only work for 1D arrays, you cannot use them while making 2D or higher arrays. Whitespace is used when you want to create the array writing the data down row-wise, so your innermost dimension in writing is actually the second dimension of the array. The semicolons are for completely consistently going from the first to the n'th dimension, with the corresponding number of ";" in each dimension.

I think it would be hard to come up with a nice way to express these in a unified notation.

The way numpy does this with lots of brackets isn't really very convenient when working in 2D, which is the more common case.

Compilation times are still an issue, but what do you mean with 'increasingly slow' compilation times? As far as I know and can tell, compilation times have been getting faster not slower, and by a significant amount.

There is a big difference between a blog post and a scientific article. A blog post should be expected to popularize a topic and reach a wider audience.

You also seem to be quite unfamiliar with breadth of the topic of mathematics. It is quite possible to take a mathematics phd without touching differential equations, except as an undergrad.

BTW, implying that people don't deserve their job is just shitty behaviour, and way out of line.

I don't think those namings are inconsistent. primitive types and abstract types are not structs, and it would be misleading to label them as such. structs and mutable structs on the other hand are.

So, using 'only struct' or 'only type' "consistently" would be more homogeneous, it would be, respectively, wrong and under-specific. I think it's good that the concepts of type and struct are separated like that.

Actually, callable structs are a common pattern in Julia, and are not in opposition to multiple dispatch.

You are probably thinking of dot-method syntax, like this

  object.action()

There's some serious misunderstanding here. You do not have to disambiguate the function call, only the construction of the object. You would write

  m1 = TensorFlow.model()
  fit(m1, data)
  m2 = Pytorch.model()
  fit(m2, data) 

Julia knows which version of model you are using.

YensorFlow.fit and Pytorch.fit are just different methods of the same function.

You've formed some strong opinions based on a pretty big misunderstanding.

Obviously, these code samples are meant only for aesthetic display, not for their pedagogical value. The criticisms being leveled by some here could be valid if their target had a different purpose. As it is, they miss the purpose and their mark.

  julia> [ (x,y) for x in 1:3, y in 1:x ]
  ERROR: UndefVarError: x not defined

I think the reason for having x and y in different scopes like this is that if the range of y depended on the value of x, this wouldn't turn into an array, where you need all dimensions to have regular length. BTW, this extends to arbitrary dimensions.

I take it multidimensional arrays aren't common data structures in Haskell?

Are there multidimensional comprehensions in Haskell? In Julia you have

  jl> [ (x,y) for x in 1:3, y in 2:5 ]
  3×4 Matrix{Tuple{Int64, Int64}}:
     (1, 2)  (1, 3)  (1, 4)  (1, 5)
     (2, 2)  (2, 3)  (2, 4)  (2, 5)
     (3, 2)  (3, 3)  (3, 4)  (3, 5)

Actually, come to think of it, Matlab is now fully jit-compiled. As long as you stick with double precision floats, there is already a "Matlab with fast loops": it's called Matlab!

Just stay away from classes and other complex data structures, which you don't like anyway, and performance is very good indeed.

If libraries use unicode in their internals, it doesn't affect you or me. And I have yet to see in the wild any examples of unicode identifiers that are required for use. The closest thing i can think of is the composition operator in Base, though it has a somewhat awkward ascii equivalent.

Do you have any example? As far as I know this is strongly discouraged in the community.

Cannot reply to deeply nested posts, so I put the answer up here:

> This is not a necessity, but an implementation choice.

The performance of Julia relies on algorithmic specialization, and since you do not know what input types your code will receive, you cannot take advantage of clever specializations. I understand that you reject the concept of allowing user types that can be used by generic functions, but then you throw all the performance out the window. I want to do fast linear algebra, but your library says "no special static arrays!", "no special handling of diagonal matrices", and in general no exploitation of special structure in user types.

I want to calculate fast derivatives, but your library doesn't accept dual number types.

Your code will never be fast if it's only fast Float64, because it's when my special type elides all computation that the real speedups arrive.

> "Specialization" is an unnecessary step when everything is explicit from the beginning.

But you cannot know what it should be explicit about. I give your `sum` function a special Range vector, or a BitVector, or a OneHot vector. What should it do? It has to fall back to the same thing it does with all arrays: add-add-add-add-add. What is the norm of my UnitVector type? Your library has to ploddingly square, sum and sqrt. In the meantime, multiple dispatch just replaces the call with the number 1.0.

> If "matlab with fast loops" is "nothing" to you, sure.

As a daily user of Matlab for 25 years, several tens of thousands of hours of grudging use, I assure you it would be less than nothing. Matlab is a tragic, horrible mess of a language, and it's not even that slow! I rue every hour I've spent on it. If Julia were slow, and Matlab faster, I would still prefer Julia.

Also, Matlab has OOP and sigular dispatch.

> But there's nothing wrong that each user has different favorite parts of the language!

Well, as I am trying to say, multiple dispatch isn't a part of the language. It is the language. Everything revolves around that concept.

> "like octave, but with fast loops"

But the performance relies on the aggressive specialization which depends on multiple dispatch. And the adaptation to numerical computing, the cleanness and beauty is all about multiple dispatch.

To stay with the bike analogy, multiple dispatch is definitely the wheels, not the motor.

> for one, I 100% agree with your views on variable naming elsewhere on this thread ;)

Waaah! (pulls hair.) And yet, so far apart on the function naming ;)

But seriously, though. Without the incredible polymorphism and genericity, there's really nothing at all left of Julia. Multiple dispatch isn't a feature bolted onto Julia. It is the core philosophy, and the central organizing principle.

> I'd prefer if the language only had a single number type

> But if you talk about the general problem of naming functions differently according to their types, I feel that it's perfectly OK.

You and I have nothing in common in this entire world.

Why on earth would you even want to touch Julia with 12 lightyear stick? The whole point of Julia is diametrically opposite to your preferences.

Being opposed to multiple dispatch, polymorphism and generic programming, while 'liking' Julia, is similar to loving bycicles, but abhorring wheels.

Long variable names make mathematically oriented code unreadable. A short half-liner becomes a multi-line monstrosity. What you need to understand is that in mathematical code, the variables themselves are of secondary importance, while the structure of the expression is primary. With long names, you cannot see what's going on.