Rust

[carlocorradini]

I'm submitting a ...

• [ ] bug report
• [X] feature request
• [ ] support request => Please do not submit support request here, see note at the top of this template.

Describe the issue The Rust programming language is increasing in popularity and becoming more and more mainstream every day. With this issue, I'd like to initiate a discussion/feature request regarding the possibility of creating Rust bindings for JSBSim. JSBSim is already compatible with Julia and Python, so why not Rust as well? 🥳 Thankfully, there are currently available several useful tools to help with the above (see bindgen). Tell me what you think 🤯

What is the motivation / use case for changing the behavior? Use the Rust programming language with JSBSim

[seanmcleod]

Having a quick look at https://rust-lang.github.io/rust-bindgen/cpp.html it looks like it might not be a simple slam dunk :wink:

[carlocorradini]

True 😬 But this can be seen as a starting point 🤯 Moreover, see https://github.com/dtolnay/cxx This is the correct tool (POC) to use and not bingen (C only)

[agodemar]

@carlocorradini did you try yourself an initial prototype of binding to Rust?

Can you summarize here the advantages in having such a new feature?

[carlocorradini]

@agodemar I have not done anything at the moment 😬

As far as I am aware, there are no Rust libraries similar to JSBSIM. Furthermore, for Julia, Python, Matlab, and Unreal, even if much difficult, having JSBSIM that is compatible with Rust is and will only be an advantage 🥳

[seanmcleod]

Just to be clear, this would simply be a binding/wrapper between a Rust program and the JSBSim engine which would still be C++ based. So if the primary reason for writing your program in Rust is due to it's better memory safety etc. compared to C++ code then the JSBSim C++ component would be a weak point, as opposed to re-writing the whole of JSBSim in Rust.

So I'm just wondering how much interest there would be from Rust developers.

[bcoconni]

I'm in total agreement with @seanmcleod

As a side note, OOP and C++ were all the rush in the late 90's early 2000's - when JSBSim was started - the choice of the language was even advertised in our description "An open source flight dynamics & control software library in C++" as can be seen on our legacy project page on SourceForge. I'm not sure that C++ had serious OOP contenders at the time, except perhaps Java ? But it has its drawbacks. @jonsberndt could certainly tell us more about the infancy of JSBSim :smile:

25 years or so later, C++ looks like an old crone to the point that the White House urges developers to avoid C++ :laughing:

Personally, would I have to start a new project today I would certainly not choose C++ as the main language. Across all these years maintaining JSBSim I have come to passionately hate C++ and I also feel that C++ is now a dead end: only projects that are already using it should continue using it.

But as Bjarne Stroustrup said "There are only two kinds of languages: the ones people complain about and the ones nobody uses".

[seanmcleod]

@bcoconni out of interest what language would you choose if you were starting from scratch?

[bcoconni]

@bcoconni out of interest what language would you choose if you were starting from scratch?

Well, that's a very personal question :smile: And this kind of discussion can quickly turn into a flame war :wink:

---

So disclaimer first: the statements below are my opinions and by no means they are meant to be agreed upon. Anyone is entirely free to disregard them and deem them irrelevant. Also I'm not a professional programmer so take all of this with a pinch of salt.

---

Currently, one of the main trend is that memory management is (or should be) a thing of the past. This leaves aside many languages such as C, C++, FORTRAN and their friends. Even if these languages now provide mechanisms to abstract away memory management, you can still ignore these abstractions (for backward compatibility reasons) and shoot yourself in the foot and blow your whole leg off in the process. Also C/C++ type management is a joke, especially C++ which can be die-hard pedantic and carefree in the same file. An example of C++ poor type management is that the C++ comity had to add the keyword explicit for constructors to avoid silent/implicit conversions 😬

I've toyed with Julia a bit (hence the binding in JSBSim) but I finally disliked it very much. Compilation times are ridiculously long (approximately 40 seconds for 600 lines of code on my old (2010) PC which can compile the same amount of C++ code in the blink of an eye). I know they are constantly improving that but as far as I am concerned it's a deal breaker. In addition, I find that Julia is not as different from the other imperative languages as its authors claim. For example I'm still wondering why they are advertising so much about multiple dispatch ? I've yet to find an example that shows how much simpler the code would be with it than without it. All the examples I've seen are convoluted examples where a problem is solved in a silly way with other programming languages to desperately try to show how much multiple dispatch make Julia code simpler. And they are heavily using templating which makes Julia code look like C++ :fearful:

Python is nice. It has garbage collection which saves handling memory management and it has duck typing which is a bless and a curse. It has a HUGE ecosystem: whatever the problem you are trying to address, Python has a library for that. I love using it for small scripts but it doesn't scale up for big apps. In addition the language is notoriously slow.

I've toyed with F# and I do love this language. It has garbage collection, strong typing and is designed for functional programming although you can use it for imperative programming. It blowed my mind several times. F# allowed me to solve a problem that I could not solve with Python and Julia. Not that that problem could not be solved with Python or Julia but functional programming forced me to rethink my approach from the ground up and the code suddenly worked ! Now I could translate this code back to imperative programming and there is no reason it should not work. Also F# showed me that immutability and type inference make your life so much easier. That being said, F# has a number of drawbacks: it uses the .NET platform which put some constraints on its design and worst of all it's not very popular (to say the least) so I would not use it for a project that is aiming a large community as functional programming in general and F# in particular scare away many people.

I've also toyed with Javascript which is as far as I am concerned "Python on a web browser". I prefer the syntax of Python however but that's really a matter of taste. Just as Python, Javascript has a huge ecosystem which has the same drawback as Python: there are so many libraries out there and these libraries depend on libraries that depend on libraries, etc. So the ecosystem is extremely fragile: if unmaintained libraries creep up in your dependencies then you're doomed. And it's extremely difficult to detect.

So what other languages are remaining ? Well, languages that I have never used such as Rust which at the moment is the cool kid in the programming language world.

[carlocorradini]

Can I say that I'll enjoy seeing debates like these where everyone can freely share/speak about their experiences and discuss the overall benefits and drawbacks of a decision/technology that willy-nilly led to the current state (C++) of JSBSim.

I completely agree with @seanmcleod that a Rust-wrapper is merely a temporary solution, similar to a patch, that will not "leave long enough" and can never be deemed a "safe" and worthwhile solution to the "problem"(s) that I and others described.

I want to set a challenge for both of us: What do you think if we work together to try to completely rewrite JSBSim in Rust utilizing cutting-edge tools and paradigms? I believe this might benefit not only me and you, but also the growing Rust community and, more broadly, the future of simulation 🥳🤯

[agodemar]

@carlocorradini

I want to set a challenge for both of us: What do you think if we work together to try to completely rewrite JSBSim in Rust utilizing cutting-edge tools and paradigms? I believe this might benefit not only me and you, but also the growing Rust community and, more broadly, the future of simulation

This will require setting up a new project. Whether this could live within https://github.com/JSBSim-Team, we should discuss it, and think about it very carefully.

Anyway, in principle, I like the idea. Are you proficient in using all the tools needed?

[jonsberndt]

JSBSim is so tied to C++ I'm not sure it's possible - nor do I think it would make sense - to port it to another language. It would make more sense to architect a new FDM from the ground up guided by the strengths of the particular language chosen. Certainly, the lessons learned through JSBSim (and other FDMs) should be kept in mind while doing so. In my day job I'm still using applications that were originally written in Fortran, and in some cases then ported to C/C++. Python is big, too.

But it is not a task to be taken lightly or underestimated. I appreciate Bertrand's comments above, and his quote of Stroustrup is very relevant, "There are only two kinds of languages: the ones people complain about and the ones nobody uses". If I was going to rewrite JSBSim I might still choose C++, but would maybe set up the architecture a little differently. If C++ was off the table, I might choose Python. No language will be a panacea and will almost absolutely result simply in another different set of issues and shortcomings. I am reminded of what Thomas Jefferson wrote about the US Constitution: "I am certainly not an advocate for frequent and untried changes in laws and constitutions. I think moderate imperfections had better be borne with; because, when once known, we accommodate ourselves to them, and find practical means of correcting their ill effects." It's a different situation, but the general idea applies: C++ isn't perfect, but under the circumstances, it works, and we can work around the shortcomings.

Rewriting JSBSim in another language really would not be rewriting JSBSim, but taking the idea and writing a new one. But, JSBSim isn't just code. It's time spent thinking and typing from 10 pm to 2 am every night for years in the beginning, with occasional stops to calm a sleepless infant. It's the coordination with similarly driven engineers, enthusiasts, and tinkerers over countless emails. It's the serendipitous appearance of unique, subject-matter experts who made critical contributions. It's luck that the original architectural path taken happened to support future growth and evolution (fairly well, at least). It was the timing with the FlightGear project that helped it surf a temporal wave of interest and usage that lead to a "critical mass" in filling a niche that needed filling. It's the fortunate adoption from students and industry that worked in the open source paradigm that helped sustain it over the years. It's the dedicated continued support of the project and user base by Bertrand, Sean, Agostino, and others. It's the contributions made by the community over the years. JSBSim is expressed through code. But, really, it's the voluntary contributions of many individual people from around the world - contributions of time, thought, study, investigation, questioning, reporting, testing, and so on.

So, when thinking of porting, or rewriting JSBSim (or any software application), it's good to think about it in those terms, too. By the numbers, JSBSim is tens of thousands of lines of code, well used, refined, and tested over decades. But there's a lot there beyond the numbers.

[bcoconni]

I want to set a challenge for both of us: What do you think if we work together to try to completely rewrite JSBSim in Rust utilizing cutting-edge tools and paradigms? I believe this might benefit not only me and you, but also the growing Rust community and, more broadly, the future of simulation 🥳🤯

Honestly, I would find this project really exciting because I love learning new programming languages. But maintaining JSBSim in C++ is already time-consuming and I don't want to spend the free time I have left doing a rewrite of JSBSim.

Also starting this project would require the few people who support/maintain/work on JSBSim, which would spread their attention that, I guess, they don't have in abundance. And keep in mind that FlightGear, the Unreal Engine plugin and the Matlab interface are designed to interact with the C++ code of JSBSim and that they would also have to be rewritten.

For those who want to rewrite JSBSim in Rust, I'll suggest to read Joel Sposky's Things you should never do first. It is telling why rewriting Netscape from scratch was a terrible idea. This blog post is more than 20 years old (it was written in Apr 6, 2000) but it is still valid in 2024. Added to the excellent post from @jonsberndt, you should now know what you are signing for 😉

[agodemar]

Well,

as of today, I have more than 10 years of experience as chief architect and manager of a 400k lines-of-code API in Java.

Looking back at all the efforts made by a group of experts in various fields to carefully: (i) choose the technology/ecosystem supporting the design, (ii) develop the structure of the API, (iii) use the appropriate design patterns, (iv) manage a few refactoring rounds, (v) plan each branching and merging transition, (vi) refining the release engineering...

I would never rewrite the software to switch to another language. In my particular case, I know now that the choice of technology was a good move: I started from scratch using Java 8; now the software is evolving towards the up-to-date Java 21. This last part hasn't been smooth (mostly because of the many dependencies), but manageable.

With JSBSim we are facing a similar situation: some developers invest their time to make sure our code base complies with the features of the new C++ standard. This brings a long-term benefit to the project.

I agree with Jon's statement: "There's a lot there beyond the numbers."