[DOC] Discuss trade-offs/advantages of Rust vs. AssemblyScript

[mikedotexe]

Is your feature request related to a problem? Please describe.
As a user, I want to make sure I'm using the correct programming language to write my smart contracts. I am unaware of the implications on storage or gas and would like to see a page detailing this.

Describe the solution you'd like
A page or section in the docs that goes over gas and storage implications of using AssemblyScript vs Rust.

Additional context

Good thoughts here from Max:
Is there anything where AS stands up more than Rust (or vice versa)?

• I doubt AssemblyScript contracts are cheaper than Rust contracts in terms of gas used. Most of the gas cost comes from the host functions that are not specific to the language. Also, Rust contracts leverage binary serialization more than AssemblyScript that uses JSON for everything. JSON is significantly more expensive than binary serialization.
• In terms of the contract size current AssemblyScript contracts that we used for examples tend to be 20% smaller than similar Rust contracts, but it does not mean we cannot write smaller contracts in Rust. In fact, we have some contracts in Rust that are 400 bytes large. It is just that we haven't added no-std option to near-sdk-rs, so that people who want their contracts smaller need to do it manually. Also, please keep in mind that 20% size is a small difference compared to the overall contract size variance that can be anything between 100KiB and 200KiB for a typical contract if you don't put optimization efforts into it. I don't really think it makes sense to worry about the contract size unless it is >>300KiB.
• Yes, AS is lagging behind in terms of functionality added. Partially because AS is a new language and we need to contribute some changes to the language itself to bring it on par with Rust. FYI Near is the largest financial sponsor of AS and we also co-organize AS community group.
• AssemblyScript (not recommended for financial applications)
• AssemblyScript is a new language that has a much smaller community than Rust. While we are contributing a lot towards its maturity and participate in its development, we need to see more signs of its maturity before we can vouch for it as a completely safe language for financial applications, e.g. having a stable version

There are many Web2 projects that could benefit from migrating or integrating with us. Many of these web-projects are built by the developers who are used to JS/TS-like ecosystem. AssemblyScript is our attempt to make the transition for the people coming from the Web2 world as easy as possible. Currently, anyone who is familiar with TypeScript can build an end-to-end application on us.

Overall, we want to have contract languages that provide a good coverage of all ecosystems:

• Rust -- for delicate financial code;
• AS -- for web-developers;
  And something we are currently brainstorming:
• Kotlin -- for mobile-developers, plus maybe backend developers not covered by Rust
  from:
  https://discordapp.com/channels/490367152054992913/510254340120903684/714528239040856114

[amgando]

@mikedotexe do you think we can just add this as-is to the intro page for contracts: http://localhost:3000/docs/roles/developer/contracts/intro or is there more work to be done to kind of "prove" the differences listed here with experimental evidence?

[MaxGraey]

In terms of the contract size current AssemblyScript contracts that we used for examples tend to be 20% smaller than similar Rust contracts, but it does not mean we cannot write smaller contracts in Rust. In fact, we have some contracts in Rust that are 400 bytes large

Hmm, in our practice difference between Rust and AS modules is not 20%, it usually several times different. Recent discussion about this.

[chadoh]

Just to add to the above, as a possible starting point, here's something I came up with a while ago for a partner:

At the language level, there are a few drawbacks to using AssemblyScript:

• No closures or dynamic dispatch (i.e. interfaces and abstract methods)
• Type system: Rust has a much more mature and powerful type system
• Smaller community: there are not many libraries available yet for AssemblyScript, whereas Rust has crates.io which has a large selection (this is probably the biggest drawback to AS right now)

In regards to near-sdk-rs vs near-sdk-as: near-sdk-as still doesn’t expose primitive actions whereas in Rust you can do things like initiate a transfer, create an account or add a key from inside a contract. (Example of a simple transfer: https://github.com/near/near-sdk-rs/blob/master/examples/cross-contract-high-level/src/lib.rs#L143; example of a full contract deployment process: https://github.com/near/near-sdk-rs/blob/master/examples/cross-contract-high-level/src/lib.rs#L48). Here's the full list of available methods on a Promise in near-sdk-rs; we are working to implement these in near-sdk-as but they're not ready yet: https://github.com/near/near-sdk-rs/blob/5339877e68736781716858149ca2191904c6284b/near-sdk/src/promise.rs#L207

[mikedotexe]

@mikedotexe do you think we can just add this as-is to the intro page for contracts: http://localhost:3000/docs/roles/developer/contracts/intro or is there more work to be done to kind of "prove" the differences listed here with experimental evidence?

I think that intro link you suggested is a great place for it. And thanks for stepping in, too, @MaxGraey, as I tend to see quite a discrepancy between Rust and AS with AS being significantly smaller than 20%. I don't want to be vague in documentation, but I think we'll want to avoid numbers figures like 20% here because we've seen sizes across the spectrum.
Great thoughts from Chad here, too.

I'm not envisioning a huge page that takes a week to write, but a few paragraphs covering what we've discussed here. I think it's quite natural for someone to ask why they should choose one over the other and I'd love to have that link in my holster ready for quick-draw. 🤠

[MaxGraey]

I would like to be clarified a little on these points:

• No closures or dynamic dispatch (i.e. interfaces and abstract methods)

Since 0.10.0 AS fully support abstract methods and partially interfaces. But closures still in progress.

Type system: Rust has a much more mature and powerful type system

Yes, Rust overall more mature language, but type system in AS pretty strong. Much stronger than in C++ or Java due to preventing implicit unsafe conversions, having nullable types and built-in null checking and etc. It still have some unsound for access uninitialized properties, which should be fixed in this PR.

Smaller community: there are not many libraries available yet for AssemblyScript, whereas Rust has crates.io which has a large selection (this is probably the biggest drawback to AS right now)

That's right. But AS is just superset of TypeScript which has pretty large community also if I'm not mistaken Neat has own runtime with non-standard persistent primitives, set of functions and etc.

Rust really has a lot more libraries and packages compare to AS, so I would say this is the most significant drawback of AssemblyScript at the moment

[akrisanov]

Hey there! After reading a few threads about Rust vs AssemblyScript thing, I didn't find any good explanation why AssemblyScript is not recommended for finance apps development except for its early adoption and the lack of third-party libraries. I totally get Rust selling points like advanced type system, memory safety, low-level optimizations, etc., but for small/medium-sized (code-wise) contracts and most of the developers do those really matter much? I agree with @MaxGraey here. Can anyone elaborate on "why" please?

[thisisjoshford]

Closing this issue as we are deprecating support for AS in favor of JS SDK.