[Rust] Generator ignores endianness

[hakejam]

Endianness can be defined using the byteOrder field. Here, the same schema uses a byte order of little endian:

<sbe:messageSchema xmlns:sbe="http://fixprotocol.io/2016/sbe"
                   xmlns:xi="http://www.w3.org/2001/XInclude"
                   package="baseline"
                   id="1"
                   version="0"
                   semanticVersion="5.2"
                   description="Example base schema which can be extended."
                   byteOrder="littleEndian">

However, the generated Rust structures do not obey this directive and always writes in whichever architecture its compiled for (e.g. x86 is little endian).

A few suggestions:

• switch the scratch data encoder/decoder from &[u8] to use Bytes or BytesMut, calling the appropriate endian read or write
• create appropriate endian versions of scratch encoders/decoders

[mjpt777]

There seems to be little interest in maintaining the Rust codecs. I'm tempted to remove them if no one is willing to support them properly.

[tmontgomery]

I agree @mjpt777

[hakejam]

It looks like there is a fair bit of interest in Rust SBE and seems like you could use some help. I may be able to help for a bit. Can we triage the Rust issues and re-evaulate in another month?

[mjpt777]

I'll give it another month then evaluate if we should remove the Rust support to have people help.

[mjpt777]

@hakejam Are you going to follow up on this?

[hakejam]

Yes, would you like them cataloged here or in a new issue? Apologies, I've been out for the holidays.

[mjpt777]

Raise issues for each and associate PRs with them.

[mjpt777]

Without progress on Rust this month I'm tempted to remove it.

[tmontgomery]

I agree.

[hakejam]

I would like to get an update out for this, but haven't had the time. I should have some time in the next few weeks to take a stab at it again.

The Rust community has appreciated the support for SBE (for example [1])! What is the cost if the codecs are kept but depreciated? Do you have active maintainers for all your supported languages?

If you're planning to remove support for Rust, I would encourage to first mark it as depreciated. Others in the Rust community may be unaware that you're intended to remove it and may have some cycles to help with PRs.

[1] : https://speice.io/2019/09/binary-format-shootout.html

[mjpt777]

The C++ and Java codecs are directly supported by us and very active. The C# and Go implementations lags a bit but are still active. The Rust implementation feels like it was someone's pet project that they abandoned and no one else stepped up. The current Rust implementation sets a poor example which does not reflect well on the other implementations. It has many obvious bugs and is a partial implementation.

I'm happy to keep it if the Rust community is will to put in a little effort. If not, then I will be removing it as carrying any code has a cost and without benefits to offset that cost then action should be taken.

[mjpt777]

Today will be the last release with Rust included. For the next release it will be removed.

[mjpt777]

Rust has been removed from project due to lack of community support.