Realtime can have a lot of different meanings… For a control loop of 100Hz Jula might already be good enough … And realtime garbage collectors exist and could be integrated … Not a hard requirement, because often you can avoid any allocation in the first place, at least for the inner control loops.
And higher level control is less time critical …
I’m not saying it can’t be done, just that it’s not currently a target (ie. something the developers are actively trying to achieve).
I’d be happy to see a realtime GC, and more soft-realtime capability. I doubt Julia will ever meet hard realtime (ie. provable deadlines, ie. controlling commercial airplane flight surfaces) but to meet those provable guarantees, hard realtime requires specialized hardware etc as well, it’s a highly specialized field.
Please let me know what commercial flights you put it on. Because I don’t want the airplane OS I’m flying on to start compiling a new method on the fly (sorry) because a helicopter entered the airspace, or because some GBs of previous flight paths needed to be garbage collected.
On that note, and since it happens to be on topic: has it ever been clarified what future Julias (1) may perhaps be able to do, and (2) definitely will never do?
For example: is real-time systems stuff à la Rust definitely in class 2 or could Julia progressively encroach into this area as the posts immediately above suggest? And could a static subset of Julia compile binaries without embedding a huge runtime, or would this fundamentally no longer be Julia?
I mean, Julia is good for rapid prototyping of control algorithms and estimators… For the final product some kind of code generation would be nice to have … Not sure in which form …
Matlab can generate C code, I think generating Rust code would be even nicer …
Is that so different from what’s already happening on GPUs?
Well, starting to compile a new method on the fly can always be avoided by calling all methods with all possible type combinations before starting the main loop… How to proof that you didn’t forget any, I am not so sure yet…
And I will use a separate process for the inner loops and the higher level control, so even a long garbage collection in the higher level control part should not cause any problem, just a sub-optimal solution of the given task.
old news; it may have hoops to jump through, but I think sometimes the rewards are worth it.
Just buffer in mid air for a bit. No biggy.
Nice paper!
I wouldn’t count Julia out of real time stuff just yet.
There’s a fair amount of activity in domains like PackageCompiler, adjusting optimization settings, that invalidation stuff I don’t understand, and I’ve seen discussion about whether you could control when and if things are compiled (there is an interpreter). So, perhaps in a few years you’ll be able to mark some things for precompilation and tell it not to compile other things, and get yourself down to only having to worry about allocations. It won’t ever be the main thrust of the language but that’s okay. Several projects have tried with varying degrees of success to enable compiling Python, surely it’s easier to take a language that already can be compiled, and sometimes only interpret it?
In the mean time I am already using it to develop control algorithms, although so far haven’t gotten away from porting the control law to C/C++ for deployment on the microcontroller.
But we talk here about the future direction of Julia. And to avoid the two-language problem is one of the promises of Julia…
I don’t want to hijack this thread about future directions of Julia, but in direct response to your comment, you might want to check out this language:
It has a graphical programming interface which is in one-to-one correspondence with an underlying pure-functional code base. They are currently working on version 2.0, which will be renamed to Enso.
It would be nice if OffsetArrays.jl would somehow become part of the core language. (As in modern Fortran, and keeping current default offsets, of course.)
That’s unnecessary. You don’t need offset arrays to use array offsets. The interface already exists in Base which is what’s necessary for composability. OffsetArrays is just an instantiation of such an interface, and in fact, people should be writing code that works for OffsetArrays without depending on OffsetArrays, otherwise that would be a clear test for interface violation.
I’d like Julia to target more the classic industry (Companies which are more conservative).
It should do that by having 2 features:
C / C++ as a call from the code / dynamic library.C / C++ code of a real world Julia code (Many functions, many used packages, on multiple platforms, etc…).C / C++ code which are not using the JIT engine. It might limit the language into a subset of features and will require specific decorations.Those 2 features will make Julia a viable option for many organizations relying on MATLAB + MATLAB Coder.
For very far future, I’d be happy with statically typed Julia.
I mean as a variant of Julia (Keep Julia dynamic, just offer a static mode, or a language derived from Julia which static, etc…).
Could that be done?
I am considering becoming a Rust programmer now, since I am already very satisfied with so many Julia packages I created. Julia is a great playground, but it can’t be used to make VST plugins or to compile flight computers on a microcontroller.
That’s why I may become a Rust developer who prototypes in Julia and then create apps in Rust.
Julia language has never paid off financially for me, but has been a nice play ground for prototyping.
Created a pull request, please comment/upvote there:
TIOBE index ? The one that put PHP, Matlab and Perl on a growth path ?
Exactly. I still need a c or c++ algorithm running inside Julia if I want to sim as I fly. Forget about using AI or optimization inside the controller. Julia needs away to target c like matlab embedded coder or it needs to cross compile. It could be done without a garbage collector or with conditions that make it unnecessary or predictable.