I have only been a user since v0.4, but updating once a year (on average) has been a minor issue for me, compared to the coding and refactoring that happens anyway. With FemtoCleaner, some of that work became automated to a certain extent.
Looking at it another way, having to update the code is the price one pays for the progress of the language. I acknowledge that it is work, but I would rather have this than a semi-dormant language.
Also, the need to continously maintain code will not stop because of v1.0, as packages get updated too.
Try maintaining a linear algebra package: Iām in the process of rewriting Ac_mul_B, At_mul_B , ā¦ 30 more cases, each of which requires its own nuance.
Not to mention thereās been random segfaults at compile time or cases that take forever to compile in pretty much every version.
I accept these problems as it is beta software, and the packages Iāve developed wouldnāt be possible in other languages. But I donāt think it helps the conversation to pretend Julia is already āproduction readyā.
I also look forward to a proper IDE for Julia. Existing development like Atom, Juypter are way far from Matlabās or R studio. I wish this can be worked on for more appreciation of Julia.
The IDE for Julia is going to be Atom/Juno, the VSCode plugin, or something like it. Perhaps a plugin for some other IDE. As far as I can tell, there is very little interest in making a dedicated IDE app from scratch.
And I think that is the right approach, itās just a question of making the plugins featureful enough and polished enough. The standalone, dedicated IDEs can be nice and powerful, but they become slow-moving dinosaurs after a while, like the Matlab IDE.
Hehe, you are 100% correct, as I should know, having suffered through them over the last 3 years (Tupleocalypse was going on right when I discovered Julia, on master, while v0.3.3 was the stable release, IIRC)
I should have put an emoji, to indicate sarcasm! (what is a good emoji for that, btw?)
That is different than saying that Julia can not be used effectively in production (with lots of care, and having somebody on the team who eats/breathes/dreams Julia, and who is willing to make PRs to fix blocking bugs and implement functionality that is missing or not performant enough).
Note that that person also runs the risk of being seen as overly pushy and critical when trying to get said bug fixes merged, since their livelihood depends on it! (Even when that person is a HUGE Julia fan-boy, who has to work hard not to accost strangers on the street or at ODSC conferences about the wonders of Julia )
The basic problem of the Matlab IDE is that it is a really outdated editor that lacks all sorts of modern editing features. My favorite example is that they are unable to implement block select (or its more advance cousin, multiple cursors).
Iām not going to start digging up a list, but git integration is missing/limited, highlighting is limited, snippet support is limited. The number of features that can be added to Atom/VSCode/Sublime/Vim/Emacs by a vibrant community is staggering. Not so for proprietary Matlab.
The Matlab editor has some very solid basic features, such as the great debugger, profiler, and good built-in graphics, which keeps them competitive for now. But they simply cannot innovate fast enough.
This is the biggest complaint about Julia Iāve heard from MATLAB users. @which works fine for me, but if youāre used to debuggers itās hard to adjust.
Simulink and the possibility to export code for real time use is important in some industries.
1-2 years ago, National Instruments had a webinar on how to integrate LabVIEW with Python. I donāt know enough about the status of that, or whether the Julia-Python integration could be used to run Julia code from within LabVIEW.
Comsol ā the company ā was originally the reseller of MATLAB in the Nordic countries, and developed FEMLab as a toolbox for MATLAB. When MathWorks took over MATLAB representation in the Nordic countries, FEMLab re-emerged as Comsol Multiphysics. So historically, there has been tight integration between Comsol and MATLAB.
Modelica can certainly handle varying mass ā Modelica is ājustā an equation based language for encoding DAEs, with good support for libraries, etc. Then there are lots of tools for operating on Modelica models, e.g., Dymola, SimulationX, OpenModelica, JModelica.org, etc., as well as Wolframās System Modeler and MapleSim.
The tools vary in how well they convert the Modelica code to executable code (conversion to C, etc.). Experience with how well the produced code (āflattened codeā) handles problems with varying mass may, of course vary, but will most likely be tool dependent.
Coming from the Fortran tradition of print sentences for debugging, the MATLAB debugger was a revelation when I learned it. Perhaps there are better methods now, but I kind of like that part of MATLAB.
The MATLAB IDE got horrendously slow when they implemented it in Java (some 10-15 yeas ago?). I switched temporarily to Python ca. 2011 due to the cost of MATLAB. At that time, I used the Wing IDE ā quite good, with a very competent and attentive developer. Iāve never really used Spyder much, and started to look into Julia ca 1 year ago ā due to some lacking possibilities in Python (control packages, etc.).
I tested MATLAB 2017 on some of my laptopsā¦ on my 2015 (?) Dell XPS 13 with 8 GB RAM and 256 GB SSD disk, it took 2 minutes to start MATLAB. Horrible. On 6 months āyoungerā Surface Pro with 16 GB RAM and 512 GB SSD disk, the start-up time was 20 sā¦
Maybe Iām old fashionedā¦ I always hated the lack of file print command in Atom ā in some cases, I prefer to sit and study printed code over a cup of coffee. I tried Juno a few months ago, and liked parts of it. Maybe Iām slow, but I never figured out how to save the layout of the various windows (command line window, plot window, etc.), so it always started with the same layout. Which was irritating.
I agree it is not production ready, but it is pretty active. FemToCleaner should take care of all those deprecations. The segfaults have happen a few times, but compile speed has been improving a lot.
The Matlab editor has some very solid basic features, such as the great debugger, profiler, and good built-in graphics, which keeps them competitive for now. But they simply cannot innovate fast enough.
I agree that itās not innovating quickly, but I would not underestimate the value of itās initial ease-of-use for average users. I think early adopters and developers (the people on these forums) often underestimate how quickly people give up on new programs when getting started is hard.
I recently tried to get a colleague to adopt Julia in place of Matlab for a graduate stats class ā students were just being asked to do things like implement Ordinary Least Squares by hand using matrices, so super easy. But when he saw the steps for getting Juno up and running (downloading Julia, downloading atom, installing the Julia client, and setting path in the juno settings to the julia download on his windows machine), his response was āOh man, thereās no way I want to deal with troubleshooting 30 students through this setup process. Iām just gonna use matlabā.
I recognize itās not first order, but I think a much cleaner, easier ādownload, click install, and then have immediate full IDE environmentā experience would go a long way towards encouraging adoption among lay-users. Stata has it, matlab has it, and R has it (both the base version has an in-built text editor, and R-Studio is very easy to set up).
In my experience, Matlab has a lot of hoops you have to jump through during install, especially with the license file/manager, toolbox selection, etc. Unless Matlab comes preinstalled, I would say itās much faster and simpler to get Juno running.
Doesnāt Juno automatically find the Julia path, btw?
Now, Matlab in general is convenient (except for the license stuff), but the question I was addressing was whether one should start developing a dedicated Julia IDE from scratch.
@BLI You have detailed nicely the history why some commercial codes have tight Matlab integration.
Of course Julia is the new kid on the block and therefore cannot boast the connection to widely used commercial codes which uses Matlab or Python (e.g. Dassault Simulia).
But my point stands, Matlab cannot yet be easily dismissed and replaced with Julia for these use cases.
Early Comsol has lots of similarity with Matlabās PDE toolbox and LabView I have used personally quite extensively for a real time experiment control system.
To gain traction in industry these things are important but unfortunately they take some time to develop.
Also, most users of Julia now are early adopters or developers, and have different priorities to end users and beginners. To get more people using Julia a focus on ease of use and good documentation will help quite a lot.
Do note that using JuliaPro imposes some restrictions on the versions of Julia and Atom packages (which might very well be a good thing in an educational context).
It does, unless you install Julia in a non-standard location.
A competitive text editor is a tremendous amount of work, never mind a fully featured IDE. I donāt think thereās any merit to starting a Julia IDE not based on one of the existing editors (and thereās a wide choice here, all the way from vim/emacs to Atom/VSCode).
Thereās a package for that: print-code. If you find that thereās something missing then Iād definitely recommend searching through Sunsetting Atom - The GitHub Blog for a packge that does what you need ā usually there is one (or lots).
The layout issue (only relevant on Macs, btw) is annoying, I agree, but itās something Iām not sure how to solve; the Standard Layout option should take care of it, but Iām not entirely sure if it works always.
(Even when that person is a HUGE Julia fan-boy, who has to work hard not to accost strangers on the street or at ODSC conferences about the wonders of Julia 
)