In case it was unclear: I don’t think that there was a feature-complete Matlab to Julia translator at any point, let alone one that yields idiomatic code that you won’t have to refactor anyway if you want performance.

Also, I don’t think such a tool is possible.

It is very rare that one can “automatically” (ie with a reasonably small cost of review and manual fixes) translate one language to another. So I think that these projects are incomplete/abandonned for a good reason.

One problem i can think of this aproach is the fact that MATLAB has a lot of toolboxes. so an adequate traslator has to consider those toolboxes and offer a replacement in julia. MATLAB and julia have different performance tips. For example the whole vectorization in MATLAB vs the fast loops of julia.
Anyway, as a new user coming from MATLAB, a page showing the direct comparisons between MATLAB and julia could be very useful, like this page from numpy.

I fully agree with @Tamas_Papp above. I think you’ll just have to bite the bullet and learn some Julia. If you intend to keep developing in Julia after this conversion, it will be a good investment anyway.

One of my first projects in Julia was converting a ~2000 line piece of MATLAB code into Julia. My approach was to convert and test small pieces at a time, starting with individual functions that could be isolated and tested for correctness by themselves. Having lots of unit tests and debug output helped a ton. Just think about correctness first, performance will come later. I knew almost no Julia as I started, but picked it up during the conversion.

Not as comprehensive as the numpy page you linked, but I found this page from the manual quite useful.

This is definitely true for the current state of technology.

It seems like such a tool would need to understand the purpose of the program as a whole, and also have a theory of mind for the humans who will later read and maintain the resulting code. We have a name for these things, they’re called “software engineers”

There’s work being done on this though, see e.g. DeepCode GmbH. But having an AI completely understand a (large) program’s purpose and re-write it in a different language is a very distant target (and would not make any sense – the AI could then just solve the problem itself, since it had to fully grasp it anyways).

Just because a problem is impossible in general doesn’t mean there can’t be useful tools, to ease the tedium of replacing () with [], linspace, ones, etc.

I am not sure these tools are that useful for non-trivial code. Anything even moderately complex ported to another language usually ends up being rewritten anyway and needs to be examined line by line.

For Julia, this is even more important because performance benefits are only realized by reasonably idiomatic code; conversely, straightforward translations can easily end up being slower. This is evidenced by topics along the lines of “my code is slower in Julia than (R|Python|…)”. IMO tools that promise any kind of automatic translation usually just lead to frustration and may even turn people away from Julia.

e.g. nchoosek is used in Matlab, binomial is used in Julia, therefore, such simple build in functions converter still not archived in http://sciencecow.mit.edu/matlab-to-julia/ or??

I think Tamas_Papp right about discouraging the use of automatic translation tools. The overlap between Matlab and Julia is high for specific linear algebra commands, but the higher level design patterns to achieve fast and flexible code can be quite different.

When I switched from Matlab to Julia, learning Julia’s design patterns was a little tricky at first. However, after some time, I began to like Julia’s design patterns more than Matlab’s. I recommend translating a simple part of your code base from scratch and once you get a hang of it, translating the rest will be relatively straightforward. If you get stuck and provide a simple working example of your problem, people are generally receptive to providing advice.

One very useful thing about this is that you can often create a line-for-line transliteration of the Matlab code. Once that works (even if it’s far from ideal) then you have something to compare against, as you re-work it into idomatic (and faster) Julia code. This is often much more relaxing than re-writing from scratch.

Anyhow I would also strongly advise against it. The languages are designed differently and hence I would not translate codes one to one. For example in Matlab everyone advises against for loops which work great in Julia.

When you want to translate the code you want to always write the best code for the language. There is not much point in simply finding the equivalent syntax, as the new language would probably be inefficient and you should simply stick to the other language. However, sitting down and actually porting code with the design of the new language in mind is something no toolbox can do.

This comes from someone who did copy a lot of Matlab codes to Julia and changed square brackets. I would say that being such an experienced Matlab programmer I am having difficulties NOT thinking in Matlab terms and this hurts my Julia experience.

I also have experience with such tools as I have used the ridiculously expensive Matlab toolbox that “translates” Matlab functions to C. If you have anything any more complex than the simplest ever example possible (i.e. the Kalman filter example from MATLAB) you run into such difficulties that it took me less time to actually write the program from scratch and teach myself the basics! Unfortunately that was after I spend excessive amount of time and energy getting the “translator” to work.

You can check out MATLAB.jl but it has some limitations and I am not sure if it works with Julia 1.1.

In any case, I would suggest to look for some native Julia packages that may provide the functionality you need. There are packages out there like Tensor.jl and TensorOperations.jl.