DNF2

This whole thread seems to be quite civilized. I can see no name-calling or off-topic rants, only a frank exchange of opinions, mixed in with some facts.

Your post seem to indicate that there is some sort of 'fight' going on, or that the tone is broken. I disagree. If most web discussions were like this one, we would have fewer problems in this world.

This doesn't really seem like a legitimate complaint. You want some particular pet behaviour, and claim it is impossible to achieve. When someone points out that it is in fact possible, you are unhappy that someone else did not anticipate and implement it pre-emptively...

Do you also expect your 'custom getproperty' (whatever it might do) to have been predicted and pre-implemented by someone else? And do you also expect arrays to 'just know' what value or behaviour you are looking for whenever you index out of bounds?

Python also allows Greek letters.

There are no Greek letters forced upon you, they aren't even used in Base, and barely if at all, in the stdlibs.

It is a feature for you to use, if you want. (And they dramatically improve code readability in heavily mathematical code.)

Yes, it was completely online. The comparison doesn't make sense.

Also, next time it's IRL the numbers would seem to indicate a huge setback, so I wouldn't use those :D

But I don't know C, and it's easier for me to be able to write fast code in a language I actually know.

Having to switch to a language you don't know is not a good situation, it doesn't help that a lot of other people know that other language.

When you accuse a lot of people of "nasty arrogance", I think it's a good idea to read your own posts and try to weed out examples of the same.

You use some pretty harsh and condescending terms as you dismiss a topic quite a few people are enthusiastic about. Is that really productive? What do you get out of it?

You also make some strange technical remarks. Julia does not allow "arbitrary subclassing" (or typing). It doesn't allow subtyping at all, except for of abstract types. In fact, composition is the preferred approach in Julia, and frequently held up as preferable to inheritance in general.

As for your preference that it's better to have good performance for only some selected parts of the language, in stead of good performance in general, that seems so idiosyncratic that I'd like a better explanation. It's hard to tell if you are serious.

I think you are confusing hype and buzz. Those are different things.

Most well-written libraries do not depend on the specific type of indexing in an array. There's a strong convention for writing index-agnostic code, with eachindex(), enumerate(), firstindex(), lastindex(), begin, end, etc.

I try to write code to accept 0-, 1-, 2-, and StarWars-based indexing.

You can think of it as similar to operator overloading. It's not quite the same, but it's a subtle distinction, or rather, the explanation of the difference is subtle.

You can find examples where operator overloading and multiple dispatch actually behaves differently and gives different answers, but the comparison works as a first order approximation.

Well, almost. Dispatch can happen at compile time, and in fact does for type-stable code. But the dispatch is on run-time types, not static types.

(The fact that you can have static dispatch on dynamic types is a pretty subtle point that hurts my head, but the upshot is that you get semantically dynamic dispatch with static performance as an optimization.)

I have also seen Matlab code match Julia for simple loops. If you write your code properly vectorized and with loops that use only calls to 'built-in' operators and C-functions, then it can match C/Julia.

But that's just extremely restrictive. The jit does not work on arbitrary user code.

Where are you getting this from? None of those features have a performance cost, if used according to some simple guidelines.

In fact, multiple dispatch is essential to get good performance, abstract types have a cost if explicitly used inside struct definitions, but that's why you use parametric types, and abstract types do not have a cost in function signatures.

Macros are expanded at compile-time, and at least have no runtime cost, in fact they are often used for improved performance.

I think there's some fundamental misunderstanding going on here, but I'm not sure what it is. Or do you mean to say that if it is possible to write slow code in a language, then only a subset of that language has good performance? If that is the case, I don't know how to respond.

The purpose of in-place operations is to avoid allocations, so this seems like an oversight.

Is this a matter of simply wrapping the 'right' LAPACK routines, or is there something missing in the interfaces that could be trivially added in principle?

I agree, the performance is a very nice bonus, but it is primarily about expressiveness, composability and natural simplicity.

It just seems profoundly un-natural and arbitrary to limit dispatch to only the first argument.

Have you looked thoroughly over https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/ ?

There's a ton of in-place operations there, including in-place solving of linear systems, and at least some stuff related to svd (though the names are pretty un-intuitive, being wrappers for BLAS and LAPACK functions).

As far as I know, multiple dispatch is optional i clisp.

It also exists in R, but again, is optional (and slow), and is therefore mostly unused, which limits its usefulness, making it less used, etc. etc.

In Julia, it is default, so everything participates in multiple dispatch. It completely pervades the language, which is what makes it so useful.

I'm sorry, but as a regular Matlab user, I have to say that, no, Matlab does not have an "excellent jit compiler." It has a jit compiler which is really limited, and works for straight-line code with built-in functions.

For performance you virtually always need to write 'vectorized' code, which is often difficult and memory heavy.

The daily churn of handling input parsing, along with contorting code into vectorized form takes up an extraordinary amount of time when writing Matlab code.

Matlab is certainly not 'good enough' for me! It's just what I'm stuck with at work.

One performance feature I find really nice in Julia, is that you can write your own function (cost function, function to integrate, whatever) that you can pass into a solver/integrator/etc. Then it will be inlined and compiled into that external library.

Does this work with numba? Are your jit-compiled functions compiled into external modules?

Perhaps I misunderstand what a 'work array' is, but you can easily pre-allocate arrays, and then work on them in-place, including with LinearAlgebra functions like `mul!` et. al.

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.

You mean the type system and multiple dispatch? I guess those are fairly minor points, yes.

I beg your pardon. What parts of Julia are not supported by its jit compiler?

If language X solves 9 of my 10 problems, and language Y solves the last one of my problems, I can either, A: use language X and call out to language Y to solve all my 10 problems. Or, B: use just language Y to solve 1 of my 10 problems.

You suggest alternative B?

The second answer in that thread, however, are links directly docs, repository and a blogpost describing the debugger. I would say the question was very well answered.

Your post gives the impression that the question was dismissed, maybe even giving the impression that there is no work on a debugger, which is quite misleading. There are several debuggers, and lots of work.

There is some controversy in the community about the _need_ for a debugger, with people with strong opinions on both sides.

As for the general tone, I don't know what to say, except that I find it quite helpful, with lots of people putting in a lot of effort to help whomsoever comes along with questions.

General (and specific) discussions about the Julia language can be had at https://discourse.julialang.org/latest (the main Julialang forum), and on Reddit https://www.reddit.com/r/Julia/

"Stop reinventing the wheel people."

That's really bad advice. Re-inventing the wheel is a good idea, and should definitely happen from time to time. If you can use new technology and ditch old preceptions, you may actually be able to make a better wheel.

Even if it fails, it's a good idea to try.

I doubt this has anything to do with 'feeling a need to identify' or anything like that. Many people who code aren't programmers, they have learnt a language to solve problems they have. They know just one language and do not have the time or capacity to learn another 'low-level' fast (but difficult) language for fixing bottlenecks.

Well, how high is the bar for calling a language 'production ready' in that case? How many production ready languages are there?

If one isn't willing to spend some time on learning a language, one simply shouldn't write a scathing blogpost about it.

As far as I'm aware, Julia interop with C/C++ is particularly excellent. So, maybe the poster can clarify?