"near clone" is a bit exaggerated. As much as I'm a free software zealot, I don't think Octave comes close to matlab yet (provided you do anything a bit more advanced than the practical of some courses)
I don’t think Matlab or Octave are great languages for software engineering. Actually, these languages are like example #1 of the difference between engineering software vs software engineering: they are excellent tools for writing, like, 10-100 line numerical experiments.
Anyone who runs up against a limitation of Octave has probably hit the point where they should consider switching, but not to Matlab or some other scripting language, but to Fortran or maybe Julia or something.
Therefore, I disagree with the accepted answer in that StackOverflow thread. The language is only good in the first place for short codes anyway, so fixing any little octave/matlab regionalisms is not a big deal. And, since it is a mathematical experiments, you should understand what every line of code does, so running the code without reading it is not really an option.
There's plenty of satellites, rockets, re-entry vehicles whose guidance and control code were designed and written using MATLAB/Simulink and then "autocoded" to C using "MATLAB Coder".
While not my preferred way of doing things, it is popular for this purpose throughout the aerospace industry.
They are never meant for general software engineer but for numerical analysis/data analysis and engineering. In fact they are quite horrible for writing general software code -- the APIs for IO and HTTP requests are very lacking compared what you can find in other languages, for example.
I haven't found a better CLI calculator utility for writing more than one-liner numerical stuff with some plots than MATLAB and octave. They're fantastic.
Matlab/Octave is great for numerical programs that perform within an order of magnitude of Fortran. If some things aren't fast enough, you can rewrite them in C or Fortran without too much trouble. If you're doing anything other than numerical computing, it's awful, and you should use a different language.
(Source: I did a PhD using a mixture of Octave for numerical stuff, Perl for text-processing and automation, and C++ for the parts that were too slow. Choose the right tool for the job.)
Modern Fortran is better all around. The compiler will check usage based on interface. It has a working and supported module system (unlike C++). A couple of openmp pragmas will parallelize it. Multidimensional dense arrays are first class objects. The compiler can emit code with array bounds checking. Keyword and optional arguments. Standardized C FFI. f2py inter-op with Python/numpy.
Most people encounter large FORTRAN IV or FORTRAN 77 heirloom codes, and assume that's what Fortran is like in 2025.
Why does this matter in the least? Like you must understand that this is a library call right? Like just put `import numpy as np` in your PYTHONSTARTUP and it's the exact same UX in python.
Anyone who runs up against a limitation of Octave has probably hit the point where they should consider switching, but not to Matlab or some other scripting language, but to Fortran or maybe Julia or something.
Therefore, I disagree with the accepted answer in that StackOverflow thread. The language is only good in the first place for short codes anyway, so fixing any little octave/matlab regionalisms is not a big deal. And, since it is a mathematical experiments, you should understand what every line of code does, so running the code without reading it is not really an option.