You don't write in assembly, do you? Every stack is implicitly doing multiple languages and some form of code generation in the process of compilation, you just don't have to know whether it's happening.
"Systems programming" as intended by Rust and as a software engineer would mean the term is a rather different thing than what you want for the purposes of embedded real-time control. There are plenty of embedded environments where if you're allowed to use C++ at all, it's only a limited subset, anything involving exceptions or RTTI is often not supported. It's tough to audit 3rd-party libraries for these kinds of restrictions, and achieve any kind of code reuse or non-trivial complexity. I'd say reducing the number of mandatory dependencies and making it possible to statically compile Julia code into minimal standalone executables and libraries is absolutely an explicit goal of the main Julia developers, just check the 0.4-projects milestone on Github. It's not there yet, but progress is being made. On Monday, September 15, 2014 1:27:15 AM UTC-7, Andrew Wagner wrote: > > Hi Tony! > > I'm a bit burned out on software systems that are pieced together out of > multiple languages, doing code generation, etc... If there's not a single > language that can do everything I need for the project, I would not start > it yet. It's really hard for me to tell at this point whether it is more > likely in the future for Julia to become suitable for systems programming, > or for rust to become suitable for interactive use... Those are explicitly > non-goals for the main developers of the two languages, so it's hard to > predict. > > Cheers, > Andrew > > On Mon, Sep 15, 2014 at 8:27 AM, Tony Kelman <to...@kelman.net > <javascript:>> wrote: > >> Slicot's not ideal from a licensing standpoint, see the earlier >> discussion from February in this thread. There is a GPL-licensed version of >> Slicot available from Debian, which works for the sake of a package. Long >> term it makes more sense to reimplement the important parts of Slicot that >> wrap Lapack to provide Sylvester and Lyapunov and Riccati solvers for >> discrete and continuous time, in base Julia. >> >> I think Jim Crist spent the summer doing a Python GSoC, so progress on >> control packages for Julia has been mostly stalled. >> >> Eventually I think Julia could make a fine platform for code generation >> of embedded controllers, hard or soft real time. Array views and the like >> will make this easier, but I don't see any reason you couldn't refactor >> Julia code to do the vast majority of allocation up-front and end up >> generating more or less the same LLVM IR that Rust's compiler would. And I >> doubt Rust will ever be as good of an interactive technical computing >> environment as Julia in terms of REPL, plotting, simulation, experimenting, >> etc. Compile-run-tweak cycles are not a convenient way to do control design >> (or much of anything, let's be honest). >> >> Generating embedded controllers in LLVM IR rather than C is currently >> very atypical, but eventually I think it could be made to work. A Julia >> replacement for "realtime workshop" is a good long-term goal. >> >> >> On Sunday, September 14, 2014 12:58:36 PM UTC-7, Andrew Wagner wrote: >>> >>> Hello again Uwe! >>> >>> It's fun running into someone I know on a language geek forum :) I'm >>> helping one of our bachelor's students implement an LQR controller on our >>> carousel in Freiburg. It's an ugly hack, but I'm calling an octave script >>> to recompute the feedback gains online. Octave wraps slicot, so if the >>> licenses are compatible, perhaps wrapping slicot is the way to go for some >>> functions, if the licenses are compatible. >>> >>> Personally, I have a burning desire for a better language we can >>> actually do control in (rust?). I doubt Julia qualifies due to the garbage >>> collection, but does anyone know if Julia has some sort of way to JIT Julia >>> expressions to code that does ~not have any garbage collection? If so, is >>> there a way to export them as object files and link against them from C? >>> Then you'd still have to write glue code in a systems language, but at >>> least the implementation of the controller wouldn't have to cross a >>> language boundary... >>> >>> Cheers, >>> Andrew >>> >>> On Thursday, February 20, 2014 10:56:20 PM UTC+1, Uwe Fechner wrote: >>>> >>>> Hello, >>>> >>>> I could not find any control system library for Julia yet. Would that >>>> make sense? >>>> There is a control system library available for Python: >>>> http://www.cds.caltech.edu/~murray/wiki/index.php/Python-control >>>> >>>> Perhaps this could be used as starting point? I think that implementing >>>> this in Julia >>>> should be easier and faster than in Python. >>>> >>>> Any comments? >>>> Should I open a feature request? >>>> >>>> Uwe Fechner, TU Delft, The Netherlands >>>> >>> >
