RuSTy Roadmap

[rohanrayan]

Hello

Do you have a roadmap of the features that you plan to implement and an approximate timeline for the same?

I was not able to find anything like this in your documentation.

Thanks

[ghaith]

Hello @rohanrayan,

We don't have a published roadmap at the moment but we should indeed work on one.
The current plan is as follows:

• Hardware channel support (%IX...) (In progress)
• Object oriented support (Partly done, but needs rework)
• Online change support. (There are some PRs open that enable basic support for OC but they are not yet complete)
• Incremental Compilation (Might be needed for full online change support)
• LSP features (maybe full LSP)
• Probably forgot things we need a real roadmap =)

Throughout we have some other smaller improvements in regards to UI and tool integrations.
We also want to support syntax that is common in codesys 3.5 which will be an ongoing effort so no set roadmap for that.

[singliuvip]

I've implemented some of the language server features so far.

[TheColonel2688]

Do you plan on implementing a full "Batteries included" experience such as IDE Integration (VS Code or something else) with Online Change support and Online Debug (Value monitoring and Breakpoints)? I know of many Codesys and Beckhoff programmers who would be tempted to migrate to Rusty eventually if they are going to get a "Batteries included" experience. Previously you had said no because this was just a hobby project. Has this changed?

Note: reaching parity with Codesys 3.5 syntax would also require support Properties, for FBs and Interfaces. Those are not in the IEC spec, but they are heavily used features that have been added to Codesys and by Extension Beckhoff.

Also, after you have reached parity with Codesys 3.5, do you plan on adding enhancements to the language? The IEC-61131-3 3rd edition is very old and rather incomplete from an Object-oriented feature perspective; also, Codesys still refuses to implement certain features from it, such as Public Scope Vars on PRGs and Function Blocks, and refuses to implement a "Class" type separate from Function Blocks.

Further, Reference types in Codesys are very limited; they are not safe for online change, meaning if the memory they are pointing to is moved during an online change, the reference target isn't moved to match. Interfaces are online-change-safe, but then we have to abuse them and use them for almost every single Function Block type, which is very tedious. Also, you can't have an array of references, only Pointers (Not type safe) or Interfaces. Talking to Codesys Corporate, they have no desire to fix any of this; they just shrug and say, "There are workarounds." (Those workarounds which I have already mentioned.)

The language desperately needs real generic types on POUs. (Function Blocks, Methods, Properties, Functions) (PRGs No, because they are signaltons and I don't think that would make sense. Please correct me if I am wrong)

After that I would say "Auto-Implemented Properties" like C#. this would help safe ALOT of time coding.

[TheColonel2688]

I've implemented some of the language server features so far.

Do you have PR to merge that into the project? Contributing back would really help the project I would think (I'm not a Rusty contributor just following the project and a big fan)

[ghaith]

Do you plan on implementing a full "Batteries included" experience such as IDE Integration (VS Code or something else) with Online Change support and Online Debug (Value monitoring and Breakpoints)? I know of many Codesys and Beckhoff programmers who would be tempted to migrate to Rusty eventually if they are going to get a "Batteries included" experience.

So there's a difference between what we would like and how we prioritize things.
I would love to reach IDE support soon, but the focus before release is on different features. The main points are codesys compatiblity,

Previously you had said no because this was just a hobby project. Has this changed?

The project became more than a hobby project it's my full time job as well as a few others.

Note: reaching parity with Codesys 3.5 syntax would also require support Properties, for FBs and Interfaces. Those are not in the IEC spec, but they are heavily used features that have been added to Codesys and by Extension Beckhoff.

Also, after you have reached parity with Codesys 3.5, do you plan on adding enhancements to the language? The IEC-61131-3 3rd edition is very old and rather incomplete from an Object-oriented feature perspective; also, Codesys still refuses to implement certain features from it, such as Public Scope Vars on PRGs and Function Blocks, and refuses to implement a "Class" type separate from Function Blocks.

The goal for the first release is codesys and oop. Codesys is because that's what people usually ask for, oop because we should have that in any sane compiler i think.
The way we are prioritizing tasks is to see if it makes sense for us, or if it's in codesys. If it's not but still makes sense for us we will still do it but maybe on a lower priority. We already have features that are not in codesys albeit not very well documented i'm afraid.
We are also currently trying to get a better concept for hardware support in and getting some ground work done for online change. These are the commits you see from embecosm. They lay the grounds for the option to reload variables and functions at runtime by abstracting their addresses in a GOT.

For live monitoring and debugging, we already have something like that working internally. The way we do it is to leverage the debug information. So you can compile the application with --debug and get address information on where each variable is. Now a runtime can read these on demand and send them to a monitoring service.

Further, Reference types in Codesys are very limited; they are not safe for online change, meaning if the memory they are pointing to is moved during an online change, the reference target isn't moved to match. Interfaces are online-change-safe, but then we have to abuse them and use them for almost every single Function Block type, which is very tedious. Also, you can't have an array of references, only Pointers (Not type safe) or Interfaces. Talking to Codesys Corporate, they have no desire to fix any of this; they just shrug and say, "There are workarounds." (Those workarounds which I have already mentioned.)

The language desperately needs real generic types on POUs. (Function Blocks, Methods, Properties, Functions) (PRGs No, because they are signaltons and I don't think that would make sense. Please correct me if I am wrong)

After that I would say "Auto-Implemented Properties" like C#. this would help safe ALOT of time coding.

In regards to properties, it's on the list, as well as namespaces, and interfaces, they are part of the OOP support for us.
I'm also sure we would support a bit more than codesys if we get the change because we try to focus on cool ergonomic features and i'm personally a fan of properties but we'll have to see :)

When it comes to references with online change, this is going to be hard to fix. The problem is how do you copy data behind a reference / pointer if the underlying struct changed. So now you need to do a deep copy which might not be fast enough for online change. I have to admit it's something we are still looking into but I understand why codesys would say no.

Other cool features already in that codesys can't :

• Code optimization
• Seamless interopability with other languages (mainly C and rust using ffi)
• Bit access using variables
  Planned features that codesys can't do (AFAIK):
• Inline variable declaration (in loops for example)
• Better generic support (We already support generics declarations but you have to implement the real methods they can just be resolved correctly)

[TheColonel2688]

The project became more than a hobby project it's my full time job as well as a few others.

It's still unclear to me what the goals of the open source project are vs the goals of your employer and how they relate to one another.

For live monitoring and debugging, we already have something like that working internally. The way we do it is to leverage the debug information. So you can compile the application with --debug and get address information on where each variable is. Now a runtime can read these on demand and send them to a monitoring service.

So there's a difference between what we would like and how we prioritize things. I would love to reach IDE support soon, but the focus before release is on different features. The main points are codesys compatiblity,

I don't see how the compiler itself is going to be useful to any PLC programmers without IDE integration; no one will use it without that (OC and Debug integrated into an IDE).

OR are you saying that IDE Integration IS on the roadmap as a prerequisite to your stable release but that it just won't be soon?

The goal for the first release is codesys and oop. Codesys is because that's what people usually ask for, oop because we should have that in any sane compiler i think. The way we are prioritizing tasks is to see if it makes sense for us, or if it's in codesys. If it's not but still makes sense for us we will still do it but maybe on a lower priority. We already have features that are not in codesys albeit not very well documented i'm afraid. We are also currently trying to get a better concept for hardware support in and getting some ground work done for online change. These are the commits you see from embecosm. They lay the grounds for the option to reload variables and functions at runtime by abstracting their addresses in a GOT.

ok that makes it more clear

When it comes to references with online change, this is going to be hard to fix. The problem is how do you copy data behind a reference / pointer if the underlying struct changed. So now you need to do a deep copy, which might not be fast enough for online change. I have to admit it's something we are still looking into but I understand why codesys would say no.

To be clear, Codesys does support this with interfaces; I obviously don't know how they do it, but I would assume that if they can do it with interfaces, they could do it with references. My impression was simply that they didn't want to bother. (I obviously could be wrong) So it is at least possible for you guys to do it, too. (yeah, I know theory, is far from implementation lol)

Other cool features already in that codesys can't :

* Code optimization

* Seamless interopability with other languages (mainly C and rust using ffi)

* Bit access using variables
  Planned features that codesys can't do (AFAIK):

* Inline variable declaration (in loops for example)

* Better generic support (We already support generics declarations but you have to implement the real methods they can just be resolved correctly)

Those all would be very much appreciated. Codesys has at least four different ways to do interops, but they are all rather incomplete and have almost no documentation. Actually, codesys is terrible at documentation in general for everything; they seem to think you should magically know how to use everything by just providing what amounts to a list of function prototypes/headers.

[jiguorui]

There is a runtime in Codesys, I think this is the main difference, Rusty here is a compiler and not a runtime for any hardware. We use Rusty to compile the ST to so or binary, it is run in native platform like Linux or Windows.

[andergisomon]

My impression of RuSTy is an ST backend that handles all the hard work: compilation, online change, live viewing. While integration with an IDE and runtime is a completely separate thing, though I could be wrong.

I'm trying to build my own, terrible, hand-rolled PLC runtime, with support for IDE-agnostic development. Been looking into using RuSTy to deal with ST support and the rest of the hard backend work. So no, I'd love to see RuSTy stick with what seems to be the main goal: an ST compiler that doesn't care about what IDE is using it.