rust-web3 VS rust

If you're deploying on Ethereum or an Ethereum testnet, have a look at this example for the web3 crate: https://github.com/tomusdrw/rust-web3/blob/master/examples/contract.rs

The partial borrow issue is from a desire to assign names to tuple indices so you can access elements without sensitivity to their order. Without that, any change to the arrangement of components in an ECS archetype would affect downstream code attempting to query-iterate those tuples. Ideally I would use an intermediate struct, but as I discovered over the course of this project, rustc/LLVM aren't great about converting between tuples and structs. The only way to be sure you're not taking a perf hit would be to use a code-generated trait to rename the tuple fields, but you can't do that because traits don't give you direct field access and you can't partial borrow from function access.

There are three. The official one, mrustc (no borrow checker, but can essentially compile the official rustc) and GCC (can't really compile anything substantial yet). Only rustc is production-ready though.

By following this issue to this issue comment, I think the reason is the sheer complexity of tuple struct constructor: * The syntax of tuple struct constructor is the same as either a function call or a constant, so to make life easier, the rust devs made it a function or a constant, i.e. declaring a tuple struct with pub fields also fills the value namespace with a function or constant. * Named field struct constructor is cannot be mistaken for a function call, so rust devs are free to let user construct them with type aliases.

Relevant rustc issue

Not that hard if you're writing Rust: https://github.com/rust-lang/rust/pull/29837 and the like.

Ah thanks, yup the last comment in https://github.com/rust-lang/rust/issues/20671 is a much more concise version of my issue :)

Looks like https://github.com/rust-lang/rust/issues/86635 / https://github.com/rust-lang/rust/issues/20671.

Love the article.

In my mind I see the problem of dynamic linking in rust to have a bunch of overlap with the "I want this rust library to be exposed in my higher level GC'd language with minimal safety/handwritten bindings" problem.

My hunch is that the lack of expressiveness of the C ABI is holding back both. the thing I'd love to see some sort of "higher level than the C ABI" come out. And something like `wasm-bindgen`[0] to exist for more languages.

Here's a link to the rust "interopable_api" proposal! I don't understand all the implications, but it seems to be in the right direction https://github.com/rust-lang/rust/pull/105586

[0]https://rustwasm.github.io/docs/wasm-bindgen/