Same situation in ecological modelling. They are not really in competition - we use them together for their relative strengths.
1 Like
This thread is making me wonder: has anyone every tried to do a survey of Julia users to ask about all these kinds of things? For a community of data users, we seem to be relying an awful lot on anecdotes here. Maybe Julia Computing might want to put together a little survey that asks users about favorite packages, what areas they perceive as needing work, questions about whether people think certain packages (like DataFrames) should be promoted to a more official status, etc?
8 Likes
Yes. In fact, JuliaCall (the library for calling Julia from R) is one of the best libraries Iāve worked with. Did you know that you can automatically differentiate (yes, AD) R functions using that library? Indeed itās true. Thatās probably one of the best R AD libraries in some abstract sense of library.
But as @Raf is saying, there are relative strengths in the R package ecosystem that havenāt been matched in Julia yet. If you ever wanted to do a ridge regression that automatically computed lambda, the easiest thing to do is to just open up R. Right now Juliaās strengths are more on the scientific computing side (numerical linear algebra, optimization, AD, diffeqs) so MATLAB should be scared. But the huge stats base of R keeps it useful even if the language is quite dreadful. Just like how Python has some nice ML and web server libraries that Julia doesnāt quite have yet.
6 Likes
To add some comments as a long time Matlab user in an academic research environment(physics).
Is Julia a direct competitor to Matlab and should Matlab be scared? In some areas, yes.
However, I see python/scipy/matplotlib and octave as more direct competitors to the common use case of base Matlab. And there the foss equivalents are a viable alternative.
What is often omitted in discussions, important functionality is fully or partly missing in all the contenders:
- For industry use Simulink is really important (automotive, telecom and aviation). There is simply no equivalent in Python, Julia, R or Octave
- Similar for toolboxes targeting real-time systems or formal code verification.
- Tight integration with leading commercial software packages (e.g. LabView, Comsol etc)
- Comprehensive and consistent documentation with example code for all functions
- A beginner friendly, just working out-of-the-box, tightly integrated environment(ide/debugger/profiler)
7 Likes
There is a lot of work being done on acausal modeling in Julia though. I donāt know about an app being in development though. But programatically Simulink isnāt even one of the leading modeling tools for this when compared to tools like Modelica (but it does have a nice point and click app).
This is being worked on.
1 Like
Sure. It should be as difficult as
I = gmt("read -Ti file.tiff");
if `file.tif`` is an image, or
G = gmt("read -Tg file.tiff");
if the file is a grid. Now, since the I type is only either 1 or 3 layers, for multi-layer files I would have to go to the GMT manual (not GMT.jl) to see how tha is done.
But we have been (similar to) here before. See this thread
Simulink is a causal modelling tool while Modelica is (mostly) acausal. Simscape would be the Matlab equivalent, though itās not as widely used or feature rich.
My post before was not a critique of Julia, I like Julia a lot. Just to emphasize some strong points Matlab still has and why companies still buy it.
5 Likes
Another reason they still buy it, simply because companies tend to be a bit conservative, and until Julia is v1.0, they wonāt touch it, no matter how much the employees ask to be able to use it instead of Matlab.
3 Likes
I thought everyone was going to acausal? What disciplines are better modeled causally (with causal modeling tools instead of just writing the diffeqs out)? Is this something we should investigate with Julia?
Itās not that easy. If i look into my own day job, where iām in research for mobile communications (with one of the bigger names ā¦) weāre a heavy matlab user (three-digit number of licenses). We have established base of matlab programs/scripts and if anyone (even heads of projects) ask for budget for reimplementation in a different environment/language we are asked tough questions. About gains and efficiencies. And user base and community and future.
The cost of maintaining matlab as SW base looks high, but the cost of changing to something else is also there.
8 Likes
Others may chime in on that question. Iām not a specialist myself in causal modelling tools so I quote:
āAfter using both (Simulink & Modelica) for almost 5 years, the only advantage that I found in Simulink is that it has better Optimisation capabilities. The MPC toolbox is a good tool. (It might also be because Simulink essentially uses much simpler equations and causal models, It would be unthinkable to code an MPC into Modelica with all its states, events and so onā.
Optimization though is already one of the strong points of Julia.
For the type of modelling we do acausal modelling doesnāt work (yet?). We have dynamic systems where values like the mass is changing a lot at simulation time, and Modelica cannot handle this. Simulink can.
2 Likes
I see, so MPC is something done better causally?
So what exactly are you looking for?
Its still an unwrapped external command. Compare that with say b ā brick(f) or stack(f) in R and how much they do with so little effort and such clear syntax.
We need wrappers that make this entirely painless. I even toyed with the idea of writing one (for GDAL) but the other 10 packages Iām writing disagree.
1 Like
That is not a quoted shell command at all. Itās just the GMT syntax. There is a new keyworded syntax being developed but itās not there yet for this case.
Sorry, either I donāt understand what you mean or I have to say again, no.
Itās a call to a julia package that parses it and send the request to an external library via ccall. For sure R is accessing to an external gdal library as well.
Not to jump in too late but my two cents regarding the 1.0 is very much a developer milestone relating to some promise of backwards compatibility making package development easier and more robust going forward. For new users I also agree with many others in this thread that this is not a sign to exchange your production language favorite for Julia. Maturing a language takes time and, while being great, Julia is still very young. Letās not forget that.
2 Likes
I totally agree, inertia is a very large factor (not just in reimplementation costs, but retraining the programmers).
I was thinking more of green field projects, where the bureaucracy might be holding people back until they can check off that at least v1.0 software box, no matter how compelling Julia might be to the programmers.
So, silly v1.0 roadblock will soon be gone, now it will be more what you said, does it make economic sense for a company to start to switch.
Itās sent as-is to a C library with C call. You are writing a command in a different language (edit: as in DSL) and to do anything complicated you need to consult the manual of that language, not the julia package.
To do anything programatically you need to do string interpolation!
Sure R calls a C library too. It always calls C.
But commands like stack() in R do some complex things while hiding the details an the external library entirely from the user, curating a seamless experience in R.
Iām not trying to attack Julia at all here. Iām just saying those commands are not yet fit for third year biology pracs, or my casual occasional use of rasters. And R is. Iām not sure how else we can improve things than admitting when something else is quite obviously a better user experience.
2 Likes
I wouldnāt call the attitude of waiting for v1.0 silly: Julia v0.1-0.7 have had a huge amount of changes which have made upkeep very painful.
3 Likes