Regarding Option 5. We still need at least one go-to language that we support as NEAR organization that we can vouch for that we can recommend to our partners, also for http://examples.near.org/ and http://docs.near.org/ . We are too early to release responsibility and control over our SDKs. Once we have enough traction and ecosystem we can delegate maintenance of the SDKs to different groups in the ecosystem.
Regarding language-agnostic Wasm-specific tools. This is a nice theoretical concept, however even ganache requires you to write tests in a specific language. We have ganache-like integration testing suite that can be used by any Wasm contracts but it requires tests in Rust. Gas-guided fuzzing is a nice theoretical concept, however, as @olonho explained general-purpose fuzz testing tools are more about having a feeling of safety, rather than safety. We can add fuzz testing and stress testing for contracts once we resolve more urgent problems, like DevX smoothness of the SDKs.
Regarding Rust support.
zero to hero time is unacceptable for quick onboarding. Just compiling code from scratch takes multiple minutes.
Do we have any data-driven evidence that compilation of the smart contracts is actually an issue to our partners? We could ask Ashley Crawford to do a survey. If you would like to have this argument then the burden of doing such research is on you. Given that Solidity contracts take approximately the same time to compile it is unlikely that anyone would see it as an issue.
smart contract sizes are too damn high: http://gov.near.org/t/raising-storage-prices-and-smart-contract-sizes/330/2 . This is becoming a practical problem for wallet already.
In the issue that you have linked it was answered that this is not an issue of Rust, but rather the fact that we haven’t added no-std support for near-sdk-rs yet. Given that AssemblyScript STD is quite minimal it is more correct comparing Rust no-std contracts to AssemblyScript contracts in terms of their size.
test on x86, deploy on WebAssembly isn’t taking security seriously
Do we have any specific evidence that this is an issue? We have compiler specialists in our organization that haven’t expressed concern about it. Besides, the integration testing suite developed by @willemneal runs contracts as Wasm not x86.
persistent collections are really confusing (this is a problem on AS side as well).
As you have said yourself, this is not a Rust issue.
To summarize, out of 4 issues of Rust that you have brought up: 2 are not supported by data, 1 is not a Rust issue, and another one is addressed in the linked URL. Also, this discussion is about AssemblyScript support.
this is very obvious gerrymandering. if you actually interpret it as choice between 2 options (Rust and JS-like), then Rust loses this survey
This is a comparison of 4 different programming languages. The intention was to show that if users had a choice between JS, TS, and AS they would’ve chosen JS. Rust was added for the baseline. If we were interested in comparing Rust to AssemblyScript then we would’ve created a Rust vs AS survey. It’s purpose is also to show that some users might not grok low-level implications of choosing one language over another, e.g. JS might not be the best contract language in terms of safety and minimalism once compiled, however many users chose it. This is to show that the choice of which language to support should not be done only based on what users prefer, but should also include knowledge of compiler experts.
With this line of reasoning we could also derive that huge parts of Rust SDK and nearcore aren’t being used as well IMO.
Finding a bug in a compiler or STD is a much more serious issue than finding a bug in a user code.
In any case this really looks like such cycle:
- deprioritize AssemblyScript
- AssemblyScript support doesn’t get a lot of cycles
- some critical bug is found later than if it was if there was more work in this direction
- use this as excuse to deprioritize further
- rinse and repeat
i.e. this is basically self-fulfilling prophecy
This is not a self-fulfilling prophecy. We did not find any bugs in Rust STD or compiler not because we are supporting near-sdk-rs, but because the language is mature. Similarly, if we put more energy into near-sdk-as it won’t guarantee that AssemblyScript compiler or STD will become bug free.
To view the outcome of that work, those interested should reference this report that was generated to summarize the first batch of sessions.
Thank you for performing this research. I see issues with the how the study was done:
- We have discussed multiple times in the past that we should not be conflating TypeScript and AssemblyScript, and even more so JavaScript. TS and AS are different languages – one cannot be called from another, they have disjoint documentation and ecosystems. We had many situations where people would start writing contracts in TypeScript only later to realize that they cannot link any of the TypeScript libraries or use TypeScript documentation or community support. In many cases once they found it they switched to Rust. For example, this happened to Anton Bukov who initially wrote a large chunk of RainbowBridge in TypeScript only to realize he cannot compile it to Wasm and cannot convert it to AssemblyScript because of TypeScript dependencies. He had to rewrite it to Rust. If we have extremely experienced contract developers like Anton confused by AssemblyScript/TypeScript then we cannot expect web2 developers to not do the same mistake over and over. @amgando was there when we have decided to not conflate TS and AS, so I am surprised to see it conflated in this research. Also, one can argue that Kotlin and Java or C and C++ have more in common than AssemblyScript and TypeScript, given that Kotlin/Java or C/C++ can be linked with each other and share the same ecosystem. The general pattern about AssemblyScript is that people are very excited developing on it, until they spent a couple of days doing it;
- The research conclusions do not mention any data, e.g. what is the number of partners answering this or that way? what is the percentage of the community answering this or that way? It is hard to conclude how statistically important this research is, what is the split between Rust vs JS audience and why it is such. The conclusion “The general sentiment of the community as it exists today is that AssemblyScript is a valuable option in the toolkit of developers interested in and currently building on NEAR.” is very high-level and does not answer the question: “how valuable?”.
- It is also not clear to me whether this research is trying to compare Rust to AssemblyScript or it is trying to figure out the value of AssemblyScript on its own;
- The research seems to be asymmetric in questions that it is asking about Rust and AssemblyScript, which might be biasing the users. E.g. questions like: “Regardless of your existing knowledge of Rust, how familiar are you with its purported benefits for authoring smart contracts?” I bet there are even fewer people that are familiar with the benefits of AssemblyScript, e.g. that it is a self-hosted compiler, etc. however this question was not asked.
I agree that it is completely unfair to expect AssemblyScript to be toe in toe with Rust. I really don’t like how our conversation about AssemblyScript support always side tracks into Rust vs AssemblyScript debate. The original post that I wrote is focused on how we support AssemblyScript independently on its comparison to Rust.
Upping AssemblyScript support is also an option, it might be viewed as an extension of Option 3. Would AssemblyScript core team be interesting in supporting it by switching focus from things like working on self-hosted compiler to co-authoring tests and STD libraries?
We really appreciate your honesty, and I would like to set expectation that this discussion is going to be happening every 6-12 months anyway. And extreme options are always going to be on the table.
Could you please help us with the following question as a subject matter expert: how difficult would it be to add TypeScript->Wasm or JS->Wasm support, compared to helping AssemblyScript getting to its full maturity?