[Proposal] add rust?

[flaviojs]

I don't want to develop in C, it's very frustrating.
Most of the bugs I've fixed would never exist in safe rust.
What is left either I don't know how to handle yet, or needs more information, or needs development.

Rust has been a pleasure to code, so I would rather move stuff to rust while fixing bugs and exploring the virtual hardware.
It would be a gradual change, without a real plan, so you can think of the dynamips code being C+rust.
However, I develop on linux so I wont be able to test stuff on macos or windows.

Also, you can think of me as a wild programmer that can disappear at any time.
If you want safety then it's better to make a release before adding rust.

In short... add rust?

[grossmj]

I don't want to develop in C, it's very frustrating.
Most of the bugs I've fixed would never exist in safe rust.

I agree, C can be very frustrating. I had fun developing in C back in the days however now it is always painful to go back to it since I code in higher level languages...

However, I develop on linux so I wont be able to test stuff on macos or windows.

Not a big issue for us. We don't intend to support macOS or Windows starting with GNS3 v3.

In short... add rust?

Well, I don't really know the amount of work needed. I would just say Dynamips will be less and less used in the future, so maybe is not worth putting in too much effort? However if it is just for the technical challenge, then yes it could be great.

[flaviojs]

Well, I don't really know the amount of work needed. I would just say Dynamips will be less and less used in the future, so maybe is not worth putting in too much effort?

As long as you stick to small self-contained work then the total amount of work is irrelevant. I'm not gonna aim for it, but as long as the base code is decent then it can be adapted for other (non-cisco) hardware. It might become useful in the future if the virtual hardware is feature-complete.

However if it is just for the technical challenge, then yes it could be great.

Cool, just need to know if I should wait for a release before starting. :)

[grossmj]

Cool, just need to know if I should wait for a release before starting. :)

I am going to do a release soon. Also, I've created a new branch named "rust". You can use it to have your PRs based on it.

[flaviojs]

Hmm, this "rust" branch thing might not work out.

It seems that my coding rate is not compatible with your time, and I make mistakes all the time.
For proper development I need someone to do a simple read of the changes to catch simple stuff (like copy-paste) and point out stuff that is unclear. You probably don't want that burden.
Alternatively I would need automated tests to document intended behavior (I'm asking for an example test in #141).

I don't have either, so I'm thinking of restarting from master and do all development in my fork's master dev branch.
This allows me to restart/rework past commits as needed without bothering you.

Questions:
1) do you want me to make bug reports for stuff that I find during development?
2) what conditions should rust code fulfill to be merged here? (I'm doing aimless development)

[flaviojs]

Ok, I gained enough knowledge to convert everything to rust.

The plan:

1. fix issues in C that I don't want to replicate in rust + convert the code to rust (in a branch of my repo)
2. do a general test with ppc32 and mips64 images (C version and rust version must behave the same way)
3. release v0.2.24 <- last release with C code
4. replace C code with rust code
5. release v0.3.0 <- first release with rust code

v0.2.24 and v0.3.0 will be the same, but using different languages.

Reason:
There needs to be a way to differentiate code translation issues from other issues.
I make mistakes all the time and there is too much code, so I'm expecting translation errors, probably:

• copy-paste errors
• wrong conversions of implicit C casts
• wrong types/macros for C defines

@grossmj
If you don't have time or don't want to bother reviewing the changes, then give me commit/merge access and I'll keep going until it's release time. I'll poke you in this issue when the time comes (or e-mail you if you prefer that).

[grossmj]

That plan works for me however sorry I cannot give you the commit/merge access since this is controlled by my org, not me. I think the best is for you to work on the forked repository and then create a PR to have everything merge once your rust code is ready. Does this sound good for you?

[flaviojs]

I though the organization was yours, guess not.

I'll be doing individual PRs for the C changes.
The rust change will be a single big PR made from scratch. The current rust branch can be deleted since I will not use it.