It was an entertaining anecdote. The kid of experience you tell people to wake them up and get interested in further investigation. Don't take is so serious Amir ;-)

The point is that you hear stories like this, and then you go do your own investigations. You look at language shootout. You look at the micro benchmarks. And as any good scientist should do, you run your own tests. If you get unsatisfactory results you go ask the Julia community for feedback. Most beginners who try porting old code to Julia and hit speed bumps tend to get relatively quickly help. The Julia community take pride in showing that Julia is indeed a very fast langauge, when used correctly.

Realistically optimized Julia code will normally be somewhat slower than optimized C or Fortran code.

You can see that in this language shootout: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/julia-gcc.html

In an idealized world of course. But in practice the flexibility of Julia will in many cases allow you to surpass C and Fortran. A JIT can pull inlining tricks which are impossible to do in language like C.

If you don't think Julia can do a 3x speedup over Python, then I question your knowledge of programming languages. Python is notoriously slow. It is an interpreted language. Most of the time when you get decent performance in Python, it is because 90 of the work is being done in an underlying C/C++ module.

But what if you have to write that code from scratch yourself in Python? Then you will see major speed bumps. Look at the language shootout for Julia vs Python: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/julia-python3.html

You got 100 - 150x speed ups with Julia. 3x.... that is piece of cake. If you cannot utilize a module written in C/C++ or Fortran then Python will completley kill your performance, unless you got special cases where you are able to utilize things like Numba or PyPy.

As for people turning away from Julia. Sure... that is something we got to better understand. I am always curious about this and talking to people. My impression is not that this happens because Julia does not support subclassing.

What I see is because Julia is immature. It does not contain all the packages a particular person might be interested in using or the tools they want.

Sometimes it is simply down to misunderstandings. I remember a guy who thought Flux wasn't ready for usage because the library looked so small in comparison to TensorFlow and PyTorch.

I had to explain to him that in Julia yo don't need to build huge monolitic libraries because small libraries can be so easily combined to create new functionality. This is a major challenge for the Julia community. We don't quite know how to inform people about this. It is a bit of a pedagocial challenge. Basically Julia has a superpower that people are not used to seeing in other languages, and so it is hard to convey how that works or why it even works.

Thus many people look at Julia libraries, and think they are toys or incomplete. They don't see how the whole ecosystem fits together. That is the problem with new languages. It takes time to develop a good story, write the books, documentations and guides that bring people onboard.

I am sorry if I sound too combative on this. I am just passionate about Julia, but I would really like to help beginners get onboard.

If I understand your concerns better, I would love to write an article on the topic.