Former Scilab intern here:

Scilab development started from the same Fortran code Matlab did, around the same time; also it rarely attempts to copy Matlab syntax or behaviour. (I'm just saying it should be seen more as an alternative to Matlab, not a copy.)

I personally would tend to agree that developing in a general purpose language is better for most problems but an imperative math-oriented language that's simple to apprehend remains a large use-case for scholars and engineers. For that I feel that the rewrite of most of the code in the past few years has been a worthwhile endeavour.

Agree with first sentence. Before mostly switching to R more than 10 years ago I tried out Octave/Scilab (and preferred the latter).

As for the alternative I'd say, Julia is (will be) a good choice also. Long in the making with a beautiful syntax which somewhat resembles Matlab. Sound "inner" foundation. And speed. Speed like no other dynamic language (important with increasing data abundance). Friendly and helpful community.

I'm scared of network effects for Julia, personally. Python is garnering tremendous amount of users.

But then, I remember a computer vision teacher 3 years ago laughing at the idea of using Python instead of Matlab as Matlab is the "obvious industry standard".

You are right that the current adoption rate of Python makes it seem like Julia is in a losing position, but on the other hand it took Python a long time to get in to the position it is right now and systemic changes take time.

The two arguments that speak for Julia from a user perspective (there exist much stronger arguments for package developers).

a; Low overhead interoperability with Python, R, C and Fortran (and C++); You don't need to rewrite your code and you can start using Julia and slowly transition.

b; User code as fast as package/base library code. You are not stuck with what already exists.

There are also some niches where Julia already has a strong position compared to Python (which I use and like), e.g. optimization and differential equations.

I think these are areas where the 2-language model makes Python quite a bit less productive than Julia.

Python has pretty good optimization support as well as handling differential equations quite well. The latter also have very good support in R. Python also handles symbolic computation pretty well and in the freeware space dominates anything else in that respect. Julia is interesting but still has a ways to go for overall flexibility.

What do you not get with Numba that you'd want?

Your question has been asked here [1]. I never used Numba myself but assume from the discussion that it is difficult/impossible to bring user objects into Numba and that due to the extremely rich Python object model one can only make Python fast for a small subset of the language.

Example: in Julia I can easily define my own primitive type, let's say a ModInteger (an old video is here [2]) and it will be as fast as a normal "built in" integer in a for loop (and benefit from possible speedups: simd, parallelization, cuda, GPU - but don't have (much) experience in this area).

Likely such a ModInteger couldn't be as easily integrated in Numba?

[1]: https://discourse.julialang.org/t/julia-motivation-why-weren... [2]: (2013) https://www.youtube.com/watch?v=rUczbQ6ZPd8 (at ~37:00 mins)

Yep I was expecting you might mention user defined types. Numba supports them but with an object model which is more sympathetic to acceleration.

The other place where Julia might see better speed is when you have an optimization algorithm and the objective function both written in Julia, which allows for optimization across functions, whereas in Python you could write a fast objective function with Numba but couldn't optimize across function call with the optimizer written in Fortran.

Julia Opt is good, but Pyomo or PULP with python are basically the same thing and Pyomo is from Sandia labs.

Numba and Loopy cover all the possible use cases for accelerated loop oriented code you could possibly want in Julia.

As someone who's watched the rise of R and Python from its beginnings, who pulled my hair out in frustration over the longevity of MATLAB long ago, and who has tried just about every numerical programming language it seems, I think the threat to Julia probably comes more from other LLVM-based languages like Nim or Crystal, or things like Rust or Kotlin.

Julia's adoption rate is really impressive compared to R or things like numpy, etc. so I'm not worried about that. But I do think it will have to contend with a number of competitors in the same space.

I think you nailed the key insight here... The Matlab community maybe needed a really close alternative at the beginning, but we should really strive now for python-centric solutions (and/or Julia/R...).

Matlab is a tremendously poor ecosystem. Not flexible at all in terms of libraries, slow, closed source and poorly designed as a language.

You could just see what Python has achieved in the last years as a scientifical tool: awesome libraries, interfaces with web/mobile applications, tons of rich courses/tutorials.

I hope it teaches other fields that open source can really be key in making tremendous progress.

I know that this is the common opinion, but I don't agree in every case. Clearly for writing an application Python is superior. But for doing calculations, I much prefer Matlab (or Octave, for really small Stuff).