For C and C++, there are standards that the compilers follow, there are tools that can be used to check for problems, and it is reliable when deployed to embedded systems. In Julia, there needs to at least be a sense of reliability that embedded systems that deploy Julia algorithms can be verified safe and accurate. For simulations that drive design decisions and verification and validation, accuracy of results is also very important.
Matlab accomplishes some of this by coding out to C or C++ and you still have to verify their coders didn’t make a mistake. Julia could do that as well or cross compile, but it won’t solve the two language problem for a lot of industries until it can be used on embedded system.
I personally like the thought of using Julia verses Intel’s One API to achieve faster development and more robust implementations. But the reliability and ability to verify is very important.
It’s about perception. Fortran is still perceived by many as some sort of gold standard for computational efficiency… not me… but you get what I’m saying.
C++ is digging itself into a hole of complexity. Python is … useful. Matlab is great but expensive for many. Julia still struggles with name recognition and perception in the engineering and software community. I think having a good story on reliability and verification gets people’s attention.
We never see Julia code being run on arduinos? Stuff like that is going to get the younger engineers. In high school FTC robotics competitions they program in Java. Perhaps there are some missed opportunities to make some inroads.
IMO, true embedded devices are dying anyway. A raspberry pi zero is $5, 512mb of ram and has wifi. Give it 5 years, and a lot less will be done on computers that aren’t powerful to run linux/Julia natively.
Well, but running Linux is a maintenance and security nightmare if all you want to do is a simple control task like in a thermostat or in a washing machine…
Think motor controllers, spacecraft, airplane navigation systems, robotics control, vehicle control and sensors, fpga based communications SOCs, radar systems, even real time HWIL systems to test all of these embedded devices. Many of these have huge SWAP constraints and tough environmental requirements or just require real-time super computing capabilities to scene generate fast enough to test these systems. Making these systems cheaper to develop, faster to simulate and test is what many of us are looking for.
For C and C++, there are standards that the compilers follow, there are tools that can be used to check for problems, and it is reliable when deployed to embedded systems.
Tools to “check for problems” are a symptom of the problem with those languages. The only tool you would want to get correct reliable code would be a compiler.
I do not believe C and C++ to be more reliable than Julia (or D) in general, and I also question them better for embedded (except for selfhosted, which Julia doesn’t support, and then there are better languages available), Julia can be used for hard-realtime, and some prefer it over C++.
What mistake has caused more grief, more bugs, more workarounds, more endless hours consumed, etc., than any other? Many people would say null pointers. I don’t agree.
Conflating pointers with arrays. […]
For strings, it’s the whole reason for the 0 terminator. For other arrays, it is inferred programmatically from the context. Naturally, every situation is different, and so an endless array (!) of bugs ensues.
The trainwreck just unfolds in slow motion from there. […]
C++ addressed the more general array problem by inventing std::vector, […] But the legacy of C arrays continues in C++ with the unsafe iterator design.
The C99 attempted to fix this problem, but the fatal error it made was still not combining the array dimension with the array pointer into one type.
But all isn’t lost. C can still be fixed. All it needs is a little new syntax:
I think all of those are fine arguments for the demise of C and C++. The tool path to HLS is pretty green, but someone will do something amazing there I’m sure.
It still is pretty unclear to me how to get Julia to be a motor controller or an autopilot on a drone or in a car.
Would it be safe enough to control the power grid or an aircraft or spacecraft? Medical equipment?
How does one validate that? How does one prove that it is that good?
While we are at it, how does one show the LLVM piece is that good for a specific target? It seems like Julia gets a free ride on the generic work to support that at least.
I would like to know more about how this could be done.
I think 90% of the people in the engineering industry are oblivious to the fact that there are safety concerns when using C++. C++ enjoys it’s status due to it’s long history of use in all branches of engineering and most importantly, I believe, because of its ISO standardisation. We engineers love standards. It’s as if everything turns gold when stamped with a 3-4 letter standards organisation.
At this point I think this becomes an issue of convincing “the large players” of giving Julia a try. Maybe standardising Julia “Core”, as I believe has already been proposed in this thread. This then can be lobbied to be included into the kinds of application you are describing.
But if we rewind the topic back to its original title, it is tricky given the issues described in the article. And it certainly doesn’t give us good publicity. There are issues needed to be solved, which I personally believe makes it a fun time to be active in the community.
From a friend programming medical equipment at a large Dutch company, I know that validation mostly boils down to testing, more testing and using “verified” tools. To give an indication of what is verified, Git got only recently approved and the C++ version is from before 2000. With this pace, they probably approve Rust and Julia around 2030. Jokes aside. If you want to make something more safe, then test more, right? I don’t get what some kind of safety stamp guarantees on top of thorough testing. Especially when talking about a language like C++ which is easy to write in such a way that few humans can read what the program does.
Jokes aside. Aren’t garbage collected languages problematic for real-time applications anyway? It’s a bit unfortunate if an airbag should go off or a plane should steer up while GC is cleaning up.
Regarding the safe enough to control the power grid. Invenia probably knows. It’s at least safe enough for planning according to Optimizing the Electrical Grid - JuliaHub
Well, not always. First of all, in Julia you CAN avoid any memory allocation in your time critical code, and then there will be no garbage to collect. Secondly real-time garbage collection with hard time limits is known for about 20 years, see for example this paper from IBM from 2003: Real-time Garbage Collection
Is it practically possible to avoid allocations or is it mostly theoretically possible? How would it be possible to avoid allocations on nontrivial codebases where the core loop consists of thousands of lines of code?
Well, my code that implements a kite power system model KiteModels.jl/KiteModels.jl at main · ufechner7/KiteModels.jl · GitHub has about 1500 lines of code and zero allocations in the core functions. This is mainly possible due to the use of StaticArrays, and StaticArrays cannot always be used… But for “classical” flight models and controllers StaticArrays should be sufficient… Probably not if you do machine learning etc., but normally you can split real-time control problems in a “smaller” problem that is hard real-time and a “larger” part, e.g. for guidance where hard real-time is not required. When using Julia each of these tasks would have to run in a separate process, but I do not see a principal problem of doing this.
Definitely have to cut down on the memory consumption. I don’t know how to measure the exact number for myself, but this blog post estimates 150MB just to run a hello-world script. Most of it is apparently Julia allocating BLAS buffers, some happened in JIT compilation, and I assume some overhead is needed for dynamic dispatch. Can anyone give a clearer breakdown of the memory usage for each feature? I could imagine a kind of executable that sacrifices even JIT compilation to save memory.
To be clear, you can absolutely design a program where you preallocate all necessary mutable data (and BLAS buffers), and after the compilation is done with, your program runs without (heap)-allocating any further data, so no more garbage. You mutate the preallocated data and otherwise work on small-enough immutable instances, which are reliably handled on the stack. Of course, you can’t use allocating code like sort; you have to search for or implement in-place versions like sort!.
For some complex programs this design would essentially mean allocating only large buffers from Julia and implementing a custom allocator on top of that.
As there is no support in Julia for custom allocators, this seems very hard to me with a lot of metaprogramming and edge cases. A real concern for me.
Even worse, multithreading is also incompatible with gc, at least currently.
Unless I’m missing something that describes an unresolved feature request (or more precisely availability of code shown in a presentation) that is more than 2 years old, but it doesn’t actually provide the macro it seems to imply?
It is way to soon to announce anything formal or concrete but we have a side project on this. Try to plug Julia to Vitis HLS.
Aaaaand that’s a nightmare. But we hope to show some (preliminary) results soon
