Every 6-12 months, NEAR revisits the degree of its support and integration of AssemblyScript. Since last time we revisited it in Feb 2020, it is time to revisit it again.

Current support and integration

Currently, NEAR supports AssemblyScript project in the following ways:

• It is the top financial contributor to the core AssemblyScript team, with monthly donations of 2k USD;

• @willemneal runs monthly AssemblyScript Community Group meeting;

• @willemneal is also an active contributor to as-pect and the core AssemblyScript code;

• @willemneal occasionally posts bounties for AssemblyScript community see: near-sdk-as

Overall, @willemneal spends only a fraction of his work time on AssemblyScript.

AssemblyScript is currently integrated with NEAR tech stack in the following way:

• NEAR has near-sdk-as. After it reached more or less parity with near-sdk-rs it’s further development was P2;

• AssemblyScript is the main language in NEAR documentation, e.g. see https://docs.near.org/

• create-near-app defaults to AssemblyScript.

Updates since Feb 2020

• AssemblyScript compiler evolved from version 0.9 to 0.17;

• near-sdk-as functionality has improved to be close to near-sdk-rs functionality and have similar DevX;

• We have started AssemblyScript Community Group which meets monthly;

• We have contract testing infrastructure in Rust that can test Wasm contracts independently on which language they are written in;

• NEAR Studio was removed and replaced with http://examples.near.org/

• Fastly announced more openly their support of AssemblyScript as an edge computing language;

• Shopify announced more openly its support of AssemblyScript;

• We stumbled upon a pretty critical bug in AssemblyScript STD which also showed that our near-sdk-as was probably not that much used, otherwise people would’ve noticed it sooner;

• @corwinharrell and @amgando did a user study on AssemblyScript. Given the choice of Rust vs AssemblyScript. 3 out of 7 people said they would use Rust, 3 said they would use AssemblyScript, 1 person said they don’t care as long as it works;

• @nearmax did a user study on JS, TypeScript, AssemblyScript, Rust. 249 people voted, the survey was not shared with any language-specific community).

Decision framework

We will choose one of the options below and commit to it for the next 6 months. Anyone in the thread can propose alternative options or express their preferences towards one or another option. Since in the past discussions of AssemblyScript lasted longer than several months we will time box this discussion and set a deadline for the decision to be January 15th, 2021. We will follow DACI decision making framework. Since the topic of AssemblyScript involves not one but many teams in NEAR Organization, @nearmax is going to be the Driver and the Approver. The following people are going to be contributors of the technical knowledge: @olonho , @willemneal , @nearmax, @evgenykuzyakov , @mikedotexe , @chadoh . And the following people are going to be contributors of the product knowledge: @olonho, @willemneal , @amgando , @thisisjoshford, @corwinharrell , @vgrichina , @mattlockyer , @mikedotexe, @nearmax. Anyone else joining this conversation can be either Contributor or Informed depending on the depth of their knowledge of the subject.

Option 1 (same support, more ownership, less integration)

Support:

• Continue the same financial support of the core AssemblyScript team;
• Continue running AssemblyScript CG;
• Get a dedicated person to own near-sdk-as, contribute to as-pect, and create AS bounties;

Integration:

• Switch create-near-app to default to Rust;
• Switch examples in docs.near.org to use Rust;

Explanation. We believe in the future of AssemblyScript and are willing to support it, but are cautious about vouching for its stability, given that compiler is not 1.0 and there are some bugs (@mikedotexe @thisisjoshford can provide more informations on issues that we encountered with AssemblyScript and near-sdk-as). Given that users are completely comfortable using Rust for the contracts, according to the surveys, we are switching docs and create-near-app to Rust.

Pros:

• We are not losing moment with AssemblyScript;
• We are getting more clear ownership of our own AssemblyScript components;
• We do not risk users starting using AssemblyScript for their contracts just to later rewrite them to Rust, because something does not work (happened to RainbowBridge and several hackathon projects);

Cons:

• We expand the scope of the horizontal teams: Berrypickers, DevRelations, and maybe Product. They now have to worry about Rust and AssemblyScript dev-tools.

Option 2 (same support, freeze integration)

Support:

• Continue the same financial support of the core AssemblyScript team;
• Continue running AssemblyScript CG;
• Freeze development of near-sdk-as and contributions to as-pect;

Integration:

• Switch create-near-app to default to Rust;
• Switch examples in docs.near.org to use Rust;

Explanation. We believe in the future of AssemblyScript and are willing to support it, but want to completely focus on a single “happy path” in our developer journey, which is Rust.

Pros:

• All pros from Option 1;
• Allows us to focus all effort on one language;

Cons:

• Having AssemblyScript support as a first-class language in NEAR is postponed by at least 6 more months.

Option 3 (external ownership without attribution without NEAR Inc/NEAR Foundation taking responsibility for it)

Support:

• Continue the same financial support of the core AssemblyScript team;
• Continue running AssemblyScript CG;
• Get a third-party to develop near-sdk-as, as-pect, and help with release of AssemblyScript 1.0, e.g. through a grant;

Integration:

• Remove AssemblyScript from our docs and tools entirely, allow third-party to develop their set of docs and tools;
• Do not vouch for the quality of the AssemblyScript dev tools as NEAR Foundation or NEAR Inc.

Explanation. We allow someone else to develop it faster, however we don’t have control over their quality and so we cannot vouch for it.

Pros:

• We are moving even faster with AssemblyScript support;
• There is no scope increase for horizontal teams like Berrypickers, DevRelations, and Product, since AssemblyScript dev-tools are now done by someone else;
• For NEAR Inc and NEAR Foundation there is less code surface that it needs to vouch for.

Cons:

• AssemblyScript devtools become disjoint from other dev-tools and documentation.

Option 4 (replace AssemblyScript with another popular language)

Support:

• Stop supporting AssemblyScript and instead support Wasm compiler for another language from the top-10 most popular languages list;

Integration:

• Remove AssemblyScript from all our tools and docs.

Explanation. As the survey has shown users prefer the idea of a more generally known language for contracts than AssemblyScript, which is what we actually care about — we want to provide an alternative that is less niche than Rust.

Pros:

• We have a more popular language for smart contracts. Some general purpose languages, like C# have stable Wasm compiler supported by large organizations like Microsoft;

Cons:

• It is unclear whether AssemblyScript->Wasm is more efficient and stable than C#(or other general purpose language)->Wasm. @olonho needs to weigh-in on it;
• There is a sunk cost of stopping AssemblyScript support.

Update 1: Removed “Rust>>JS>>TypeScript>>AssemblyScript” to not confuse people. As @vgrichina pointed out.

I think we forgot:

Option 5 (focus on making it easy to support any language of choice, which is main selling point of WebAssembly).

Our runtime API is generally pretty small and easy integrate into any language which supports C-style APIs.
This means we can demonstrate this to community by showing how e.g. you can build minimal smart contract on C, no_std Rust, Swift, TinyGo, etc.

This also means we actually need to provide WASM-specific (but language agnostic) tools which allow shipping secure code:

• integration testing support (drive minimal node like ganache vs bake in support for Rust). Current way of testing Rust code is actually pretty scary: we compile for x86 using basically far more mature compiler backend than WebAssemby and run in completely fake environment. I believe some of the teams already noticed discrepancies, but hard to find now in chats.
• fuzzing at both binary args level and individual arguments / storage state / etc. @willemneal had pretty good insight that we can use existing gas instrumentation code to drive fuzzer basically. Which makes even more sense given that it’s pretty important to discover pathological gas usage for given inputs.
• stress testing tools. We had pretty bad bugs in nearcore (like with access keys recently) caused by lack of stress testing. We should make it easy to stress test.

Pros:

• we are seen as more neutral
• opportunities for community contributions (many developers love making frameworks from scratch more than apps. I think Rick Tobacco already mentioned wanting to do C++ SDK on TG)
• access to larger talent pool (WebAssembly fans are particularly excited to use their language of choice with a new tech stack, at least SF WASM Weekly crowd)
• robust tools which help to have better security for every language without trusting any specific language implementation

Cons:

• we can get blamed for problems even with languages we don’t support (questionable as will happen anyways. Example: wallet getting shit for Marlin staking UX issues)
• more work then when we aren’t doing fuzzing / integration testing tools

I also suggest we seriously revisit out Rust support as well:

• zero to hero time is unacceptable for quick onboarding. Just compiling code from scratch takes multiple minutes.
• 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.
• test on x86, deploy on WebAssembly isn’t taking security seriously
• persistent collections are really confusing (this is a problem on AS side as well). I think we better should use ActiveRecord pattern familiar to many web and backend developers. Or anything else which is more like “define table, make queries” vs manage indices myself by hand.

• @nearmax did a user study on JS, TypeScript, AssemblyScript, Rust. 249 people voted the following preference on the languages: Rust>>JS>>TypeScript>>AssemblyScript (the survey was not shared with any language-specific community).

this is very obvious gerrymandering.

if you actually interpret it as choice between 2 options (Rust and JS-like), then Rust loses this survey

when choosing from hypotheticals I myself want to use JS (and voted JS).

however AS is closest alternative we can actually have running on WebAssembly

Great summary @nearmax! One small adjustment I wanted to make: The link you have provided for the user study conducted by @amgando and myself is actually just a one-off survey that I shared on twitter that didn’t see much engagement. While still relevant, these survey responses are not reflective of the 1:1 sessions that @amgando and I also facilitated. To view the outcome of that work, those interested should reference this report that was generated to summarize the first batch of sessions. The TLDR outcome of this research, as outlined in the report, is as follows:

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. Developers like what is familiar, as it helps them to start and make progress faster/easier. As a result, there’s a general preference for familiar languages like TypeScript (and AS by proxy) over Rust without necessarily grokking the implications or benefits of the latter.

It may be beneficial for those diving into this to surface this in the summary as well.

I am very grateful for NEAR’s invaluable support to AssemblyScript, it really makes a difference as we wouldn’t be where we are today without you, but I am a bit surprised by two points.

First, that Rust isn’t already the default, as a stable foundation while WebAssembly is still an MVP, also given how slow the specification is progressing. WebAssembly hasn’t made any progress to help managed languages yet, and expecting AssemblyScript to compete toe to toe with a systems language at this point in time is unrealistic, just as it is unrealistic to expect AssemblyScript and its very small team to compete with Rust/LLVM in general. I mean, we are doing our best, often beyond a healthy limit, but there is a difference in multiple magnitudes of financial support, human resources and influence on the specification process between the Rust and AS ecosystems still. In fact, comparing the two for stability or applicability in the current state of affairs is starting to do more harm than it helps, because AssemblyScript and its people can only lose.

Secondly, that upping your support isn’t an option given how much you rely on it. It would already help a ton for example to assemble a temporary but dedicated team testing the hell out of the compiler and its standard library and PRing the tests upstream so you can be certain that it meets critical demands in production, no matter how boring that work is. Not maintaining a fork, no uncommon code style, and no outdated compiler versions, as it happened in the past. I do agree of course that the string compare bug was particularly embarrassing, yet it not being found earlier is a statement with multiple dimensions. With broader adoption it would have been found earlier, as it would have been found earlier with focused adoption.

I know that this may not be what you folks want to hear from me, and that it may fuel the fire of burning AS down at NEAR in those wanting to, but perhaps my honest opinion will help you make a forward-facing decision that will ultimately result in your success. I definitely owe you that.

nearmax:

• We stumbled upon a pretty critical bug in AssemblyScript STD which also showed that our near-sdk-as was probably not that much used, otherwise people would’ve noticed it sooner;

With this line of reasoning we could also derive that huge parts of Rust SDK and nearcore aren’t being used as well IMO.

BTW I don’t think TreeMap was really used in any of our examples or that they had any good reason to do string comparisons otherwise. Most contracts would retrieve few keys, update some numbers, write keys back. If sorted list is needed, etc I think most use cases end up using indexer vs maintaining sorted list on chain.

Same goes with AssemblyScript usage in general outside of NEAR. It’s usually some heavy number crunching (gameboy emulator, chess engine, etc), not really focused on strings. Which is likely main reason this wasn’t found before.

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

@vlad

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.

@corwinharrell

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.

@dcode

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?

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?

You could build a TypeScript->Wasm or JS->Wasm compiler, or fall back to run unmodified JavaScript directly by either embedding V8, or compiling an interpreter like quickjs to Wasm to run unmodified JS through either of these. The latter options aren’t necessarily difficult, but have other drawbacks like that V8 is huge and that interpreters are slow.

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?

I’d be very interested in merging more tests upstream and fixing issues discovered in the process, but ideally in a way that I can still focus on milestones like bootstrapping as it achieves invaluable confidence into the compiler or general progress on fronts not many people can help me with. I am sure that others on the team would also welcome PRs for more standard library tests and issues discovered in the process to fix. If that helps?

@nearmax thanks for this feedback. It’s good to know where your head is at and I think your observations about what I’ve shared are completely valid. It’s clear that I could’ve provided some more context about the summary that I authored.

Regarding how the research was conducted:

I first want to give full disclosure that my role in these sessions was primarily one of coordinator and handling of logistics as well as record keeping. I am not a smart contract developer, and my experience and exposure to Rust and AS is limited, so I’ve relied heavily on @amgando to offer his expertise in evaluating the development capabilities and perspectives of the candidates that we were able to sit with for this research. I’m sure he can weigh in here or elsewhere to provide some more nuanced insights and to help fill in the gaps as far as communicating learnings from these sessions where I am unable.

The research conclusions do not mention any data, e.g. what is the number of partners answering this or that way?

You’re correct in that this particular summary report was entirely qualitative and does not contain sufficient quantitative metrics to be useful as a tool for evaluating specific criteria. My initial intent for the report was just to provide the larger org with a summary of the work that had been done, and to relay the general sentiment from participants that we had observed.

In my role as coordinator, I didn’t want to misrepresent specific smart-contract related learnings from the tests/tasks that @amgando had designed, since my ability to interpret participant behavior in this context is fairly limited. As a result, the summary definitely falls short when considered as a definitive source of quantitative data. I will be going back over the session data with @amgando to provide more quantitative insights in a form that is more useful as a reference for decision making.

We have discussed multiple times in the past that we should not be conflating TypeScript and AssemblyScript, and even more so JavaScript…

If this is the case, this was definitely lost on me personally. My impression from how some of these questions about developers’ language preferences have been framed is that the audience that is most likely to favor AssemblyScript are those with a JS background who view the path from JS > TS > AS as the path of least resistance. This seemed to be the sentiment shared by most of the individuals we talked to over the course of the research. If there have been discussions about the fact that these things should not be conflated, then I was not privy to this and this definitely had an impact on how I perceived the sentiment of participants.

@amgando lets definitely circle back to see what quantitative insights we can extract from our sessions to hopefully provide @nearmax and team with the specific references they need to better inform this decision making.

Just to be clear my arguments “against” Rust are purely to use it as a baseline to establish which trade offs we are making between languages, not to attack Rust development.

I personally think we should enable multiple languages – this is whole point of WebAssembly. Also generally trade offs between languages often are highly subjective and every OS typically has different languages for different use cases. I don’t think 100m Defi projects and Berry Club’s of the world should be using the same language.

Regarding language-agnostic Wasm-specific tools. This is a nice theoretical concept, however even ganache requires you to write tests in a specific language.

This is not true. You can interact with ganache via RPC from any language. You probably aree confusing with Truffle which provides JS testing framework (and there is very huge difference between providing JS and Rust as options, JS is vastly more popular and familiar).

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.

So let’s decide whether arguments should be backed by data or deferred to authority, as you seem to be doing either

What I know for sure is that if we don’t fuzz for trivial issues – attackers will do it.

I agree 100% it’s not going to be guarantee of security however, same as literally anything else.

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.

I’ve seen somebody on our chat groups complaining about discrepancy when running on-chain. It is hard to find it now unfortunately. However WebAssembly has some design choices that often affect other language implementations seriously (e.g. 0 being valid pointer).

Besides, the integration testing suite developed by @willemneal runs contracts as Wasm not x86.

This is good news.

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.

We don’t have data but given you are deferring to experts I will do to – @corwinharrell what do you think. Will around 10x bigger project startup time is likely to be affecting conversion rates?

Closest things I have is data on how many repos are using respective libraries on GH:
https://github.com/search?l=TOML&q=near-sdk-rs&type=Code
https://github.com/search?l=JSON&q=near-runtime-ts&type=Code
https://github.com/search?l=JSON&q=near-sdk-as&type=Code

This obviously has a lot of confounding variablew but if anything shows that AssemblyScript SDK is pretty popular choice for public repos using NEAR and seems to get more popular over time (compare near-runtime-ts to near-sdk-as).

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.

I’m excited for no_std, but we are de-facto right now on mainnet having 10x higher cost on contracts which are deployed using Rust vs AssemblyScript, so it doesn’t matter what Rust can do in theory.
For many projects it’s crucial to have contracts deployable by users. AS currently provides practical advantage here for now.

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.

How do you think it did become mature? People were using it more and more and finding and fixing bugs.

Similarly, if we put more energy into near-sdk-as it won’t guarantee that AssemblyScript compiler or STD will become bug free.

I didn’t ever try to imply it’ll become bug free. No software is bug free. Take for example Rust:

Issues · rust-lang/rust · GitHub (2k+ unresolved compiler bugs)
Issues · rust-lang/rust · GitHub (WASM specific compiler bugs)

We just would identify more bugs and get them fixed, exactly like happened for existing problems. AS folks are pretty responsive for actual bugs.

Finding a bug in a compiler or STD is a much more serious issue than finding a bug in a user code.

nearcore isn’t your normal user code. It’s OS code on which we execute user code (smart contracts). near-sdk-rs is STD from NEAR devs point of view.
nearcore bugs are arguably far more impactful than anything in smart contracts.

The intention was to show that if users had a choice between JS, TS, and AS they would’ve chosen JS.

Among 3 similar languages users have chosen most familiar and flexible and generally voted according to relative popularity of languages. No surprise here, except I didn’t expect Rust to have less votes than other languages in total. I’d prefer to use JS myself everything else being equal.

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.

It’s not clear from survey you need to take these implications into accounts. Like in theory you can make JS system optimized for blockchain usage (i.e. pre-compile into intermediate code during deploy, make VM startup faster, etc).

As for safety I highly disagree this is top priority for every use case. It definitely is top priority on ETH as with $10-$200 transaction cost the only viable use cases are capital heavy and so super risky. Still ETH somehow managed to pull it off with extremely immature purpose built VM and language. NEAR brings transaction cost down and makes use cases with less capital involved (e.g. Berry Club, Paras) far more viable. Which means speed to market can often be far more important than safety.

Also check out pretty interesting research (http://earlbarr.com/publications/typestudy.pdf). Having static type checking empirically is preventing around 15% of bugs compared to plain JS projects. However this still means 85% of bugs are happening regardless. So it is an improvement, but not even close to order of magnitude improvement.

@dcode We need to run a non-optimizing compiler so that the compilation cost can be approximated from the program size.

I’d be very interested in merging more tests upstream and fixing issues discovered in the process, but ideally in a way that I can still focus on milestones like bootstrapping as it achieves invaluable confidence into the compiler or general progress on fronts not many people can help me with. I am sure that others on the team would also welcome PRs for more standard library tests and issues discovered in the process to fix. If that helps?

This helps, thank you. If we decide to contribute to the stability of the AssemblyScript compiler and STD we would be grateful if we could have a joined planning and get a commitment from AssemblyScript core team.

@corwinharrell Thank you for coordinating the research. I am sure it took a good chunk of your time. Regarding not conflating JS, TS, AS, we unfortunately have stories that I shared above when we sold AS as TS to users and they had to redo their entire project because they were operating under wrong assumptions. Please get back to us with the quantitative data ASAP, since we would like to make this decision by EOW.

@vgrichina

I personally think we should enable multiple languages – this is whole point of WebAssembly. Also generally trade offs between languages often are highly subjective and every OS typically has different languages for different use cases. I don’t think 100m Defi projects and Berry Club’s of the world should be using the same language.

There are two issues with focusing on making our devtools language-agnostic:

• We are operating under limited resources and time. It is much easier and faster to achieve a polished end-to-end development experience when we are focusing on single primary language than if we are trying to generalize it to all languages. It makes life of Contract Runtime, Berrypickers, DevRel and DevCommunity teams much easier. Once we have polished it for one language we can think of how we will be generalizing it to other languages;
• Language-agnostic devtools is only a vision. It is unclear how it would translate to specific technical designs, and whether some of it is even going to be feasible.

This is not true. You can interact with ganache via RPC from any language. You probably aree confusing with Truffle which provides JS testing framework (and there is very huge difference between providing JS and Rust as options, JS is vastly more popular and familiar).

Correct, I mean Truffle. Thanks for correcting.

So let’s decide whether arguments should be backed by data or deferred to authority, as you seem to be doing either
What I know for sure is that if we don’t fuzz for trivial issues – attackers will do it.
I agree 100% it’s not going to be guarantee of security however, same as literally anything else.

The decision making is done used by both data and expert opinion (not to be confused with authority). I would expect opinions on what market prefers to be backed by data and opinions of feasibility and safety to be backed by expert opinion, since general audience is not familiar with implications of choosing this or that compiler.

To understand whether we want to spend any time on fuzzers and how we prioritize it against other work items, we need to understand the potential impact fuzzers might create, how much our users will value them, and whether there are better alternatives, e.g. making our integration testing framework more polished. Please feel free to follow up with Berrypickers on collecting data from our community on how useful it might be compared to other options.

We don’t have data but given you are deferring to experts I will do to – @corwinharrell what do you think. Will around 10x bigger project startup time is likely to be affecting conversion rates?

As explained above, I would defer to experts only when it comes for opinions on deep tech, e.g. is there any JS->Wasm compiler that is safe to use? Is AssemblyScript compiler stable enough to not accidentally cause UB? Market preferences should be backed up by data.

Closest things I have is data on how many repos are using respective libraries on GH:
https://github.com/search?l=TOML&q=near-sdk-rs&type=Code
Code search results · GitHub
https://github.com/search?l=JSON&q=near-sdk-as&type=Code

This is interesting data, thank you! (don’t forget that near-bindgen was an old name for near-sdk-rs) I wonder how much the fact that http://docs.near.org/ uses AssemblyScript examples has biased people trying NEAR Protocol to create more repositories with AssemblyScript examples compared to Rust examples.

I’m excited for no_std, but we are de-facto right now on mainnet having 10x higher cost on contracts which are deployed using Rust vs AssemblyScript, so it doesn’t matter what Rust can do in theory.
For many projects it’s crucial to have contracts deployable by users. AS currently provides practical advantage here for now.

I don’t think 10x is a fair comparison. The size of the contract does not grow linearly with its complexity, especially when people start importing external dependencies. Given that AssemblyScript ecosystem has almost no libraries it biases people who want to write complex projects to choose Rust over AssemblyScript since they don’t want to reimplement all the dependencies themselves. So 10x difference could be a signal that people do not use AssemblyScript for anything medium to high complexity.

How do you think it did become mature? People were using it more and more and finding and fixing bugs.

Rust became mature by being supported by Mozilla with dozens if not hundreds people paid to continuously improve it.

We just would identify more bugs and get them fixed, exactly like happened for existing problems. AS folks are pretty responsive for actual bugs.

Identifying and fixing bugs in a compiler and STD is a huge undertaking, unlike other software projects. It took Rust 9 years and the backing of Mozilla to become a stable compiler. It took Go lang 5 years and the backing of Google to become a stable compiler. AssemblyScript has ~2 core developers and has started development around 2019. Support from NEAR creates a big impact for AssemblyScript, however, we need to be honest about the degree of complexity we are talking about here. Even if throw our entire organization at it, if history is an indicator, it would take many years and dozens or hundreds more people working on compiler + STD (not to be confused with people just using AssemblyScript) to get it to a stable state.

nearcore isn’t your normal user code. It’s OS code on which we execute user code (smart contracts). near-sdk-rs is STD from NEAR devs point of view.
nearcore bugs are arguably far more impactful than anything in smart contracts.

I disagree, nearcore+near-sdk-rs is not as low-level as compiler+STD.

Among 3 similar languages users have chosen most familiar and flexible and generally voted according to relative popularity of languages. No surprise here, except I didn’t expect Rust to have less votes than other languages in total. I’d prefer to use JS myself everything else being equal.

The survey is actually an indicator that we cannot rely on the preferences of the community alone when deciding whether to support certain language as a contract language. JS might be the most favorite language, but regular developers do not know that JS contracts might be incredibly large in size once compiled to Wasm, or that JS->Wasm compiler is not production ready. Similarly, we cannot rely only on the opinion of the community whether to support AS->Wasm compiler and we should be using opinion of compiler experts in our organization.

It’s not clear from survey you need to take these implications into accounts. Like in theory you can make JS system optimized for blockchain usage (i.e. pre-compile into intermediate code during deploy, make VM startup faster, etc).

We might be able to do that, but it might be much more difficult than doing it for other languages, even TypeScript.

As for safety I highly disagree this is top priority for every use case. It definitely is top priority on ETH as with $10-$200 transaction cost the only viable use cases are capital heavy and so super risky.

Our requirements is a super set of Etheruem requirements. What you are saying is that we can be focusing on being faster at a cost of being safe, because ETH ecosystem biases use cases to be capital heavy. However, we also have capital heavy use cases. In fact, our fist step in org strategy (that will be presented by @illia) is addressing existing capital heavy market. So we need to be both safe and move fast.

Still ETH somehow managed to pull it off with extremely immature purpose built VM and language. NEAR brings transaction cost down and makes use cases with less capital involved (e.g. Berry Club, Paras) far more viable. Which means speed to market can often be far more important than safety.

I expect people to compare our quality to the present days Ethereum not early days Ethereum.

Also check out pretty interesting research (http://earlbarr.com/publications/typestudy.pdf). Having static type checking empirically is preventing around 15% of bugs compared to plain JS projects. However this still means 85% of bugs are happening regardless. So it is an improvement, but not even close to order of magnitude improvement.

That’s correct. Thank you for sharing this link even though it does not fully support your point. We might want to focus on polishing our integration testing suite instead of focusing on static analysis or fuzz testing.

Think Option 5, while highly attractive is hard to do practically. So my personal inclination here around Option 3 or Option 4, with C++ as the language. It may sound strange, but C++ after 14 (see C++14 - Wikipedia) become rather attractive language due to type inference, lambdas and such. Another possible option is Lua (GitHub - vvanders/wasm_lua: Lua VM running in a WASM environment).

Another option is to provide tooling which automatically generates Rust contracts out of simple wizard/graphical language, so that initial bootstrap is handled by tooling, and then developer can have functional contract immediately. For example Scratch educational visual programming language (Scratch (programming language) - Wikipedia) is OSS and could be tuned to produce smart contracts.

As an educator here’s what I’ve noticed that’s relevant to this discussion:

Developers may like the idea of writing contracts in a language they believe they already know.

Capturing mindshare is a difficult game. The phrase “AssemblyScript is like TypeScript” makes NEAR an attractive option in a sea of (some very) esoteric alternatives. The perceived “low opportunity cost of exploring NEAR” is likely a major factor in attracting developers to our platform in the first place. It would be imprudent to ignore the potential impact of extinguishing this lighthouse of engagement.

And although it is true that this has lead to significant confusion in the past (as presented by @nearmax above), our documentation and examples made a hard switch in how we frame AssemblyScript around Q1 2020 to address this confusion. I believe this switch in our messaging was effective but have not done the due diligence to support this claim beyond the anecdotal evidence that several non-trivial Hack the Rainbow submissions were written in AssemblyScript.

“NEARly thinking” is a process that does not require extreme levels of rigor at the outset

NEAR boasts a unique account model that is at once both trivial for web developers to understand and yet consistently disorienting for Ethereum developers. NEAR’s composable actions, asynchronous cross-contract calls, permissioned access keys and other features are also part of NEARly thinking.

It takes time for people to wrap their head around these ideas – let alone “why blockchain?”.

For the average developer – I’m speaking here of people like me who have never dreamed of applying to compete an ICPC event – this early learning time is better spent adapting to the many new and innovative mental models of NEAR rather than fighting with the Rust compiler.

For this reason, AssemblyScript (or any other low-overhead, prototype-friendly) development is a valuable rung in the mass-adoption ladder.

Insisting on Rust may inadvertently stifle innovation among our community members

Reducing or eliminating support for AssemblyScript has the very likely impact of

• reducing the number of incoming developers (see above two points)
• increasing the barrier to entry for new developers (Rust learning curve) and
• threatening our appeal to underrepresented groups in tech (this is a topic for another time)

Rust programming is not “smooth” (as experts admit). The ROI on this masochism is the unprecedented safety needed for money and identity.

The increase in difficulty of fluid self-expression through code is likely to make people less playful, less creative and therefore less innovative with their contributions as they hesitate to take on the lonely, little death of one failed build after another.

In this regard, AssemblyScript (or any other language designed for, or associated with, play) is a valuable asset to our community.

Having said this, I can not defend with numbers the anecdotal evidence collected in my work with @corwinharrell (as @nearmax invites us to do above). The design intent of that research was to gather user stories through expert observation.

We spent several hours pairing with developers as they struggled towards NEARly thinking.

I was left with the distinct impression that the syntactic familiarity provided by AssemblyScript during the learning process reduced cognitive load to the point that developers were able to reason about the system and draw meaningful conclusions free of distraction from the compiler.

Based on this discussion I would weigh in with something between Options 3 and 5

Specifically:

1. Recognize AssemblyScript as an effective onboarding tool to the NEAR platform for JavaScript / TypeScript developers and as a medium for creative early contract design work along your NEAR journey. Now is the time to attract and retain new developers, not 6-12 months from now. I tried to make this argument above.

2. Transition to focus all our internal, tightly integrated efforts on a unified technical runway paved in one language: Rust, to de-risk our ability to deliver on our ambitious goals (Option 3). @nearmax makes a sound case for this above.

3. Fund one (or better, many small) external partner(s) to take on the challenge of owning and improving our AssemblyScript tooling as well as other languages and programming environments. This fund should be significant and reflect the far reaching ambitions of this project with focus on the most popular languages by adoption volume first. (Options 3+5) @frol, @vlad and @olonho make good arguments for this above.

4. Hire a competent, capable internal representative as liaison to external partners. This role would be dedicated to maintaining something close to parity between internal design changes and external development efforts so we don’t outpace our partners and threaten the integrity of their work. Although this point is only briefly mentioned above, divergence across organizational boundaries will become a big risk after separation of responsibilities. This may require more than one FTE. (Option 5)

@amgando

Capturing mindshare is a difficult game. The phrase “AssemblyScript is like TypeScript” makes NEAR an attractive option in a sea of (some very) esoteric alternatives. The perceived “low opportunity cost of exploring NEAR” is likely a major factor in attracting developers to our platform in the first place. It would be imprudent to ignore the potential impact of extinguishing this lighthouse of engagement.

To paraphrase, the choice of calling AssemblyScript a TypeScript is a marketing choice. There are however pros and cons to doing this bait and switch. We have examples of projects suffering from finding out AssemblyScript is not TypeScript. Their disillusionment hurts our image, and we have actually measured through surveys how much the image of NEAR drops in eyes after users actually try writing contracts in what is sold to them as TypeScript to later find out that this is not a TypeScript. It is unclear whether pros outweigh the cons.

The other issue, is that we have explicitly agreed as an organization to not call AssemblyScript TypeScript. It is unclear why this was reverted for that research.

For this reason, AssemblyScript (or any other low-overhead, prototype-friendly) development is a valuable rung in the mass-adoption ladder.

I agree that AssemblyScript is valuable. The question is how valuable? Supporting AssemblyScript comes at a cost, do the pros outweigh the costs?

To summarize. If we want to argue in favor of supporting AssemblyScript we need to answer the question: “How exactly is AssemblyScript valuable for NEAR?”. Instead the question that was mostly answered in the replies in this thread is “Is AssemblyScript valuable for NEAR?”. The default choice for committing to any technology in our organization is no – that is there needs to be a reason to commit to something, not the other way around. There is however an exception when we cannot evaluate value of something without committing to it, and so we run an experiment with the goal of collecting the data. We’ve been supporting AssemblyScript for several years now, however it is unfortunate that we haven’t used this opportunity to collect the data to answer the question: “How exactly is AssemblyScript valuable for NEAR?”. The experiment, however, cannot run indefinitely, because the nature of experiment is that it is temporary.

nearmax:

I agree that AssemblyScript is valuable. The question is how valuable?

what kind of data do you need to show that AssemblyScript is valuable.

right now there is

• deep UX research from @corwinharrell and @amgando showing users prefer AssemblyScript and don’t have good understanding why would they use Rust instead (having 200m locked in smart contract would be good example, maybe we need to make it more clear)
• your own survey showing that 58.1% of people prefer to use JS-like language over Rust
• 239 total GH matches for AS SDK vs 73 for Rust.
• top-grossing third-party dapp on NEAR is built using AS SDK (Paras) and generally is a solid case study of web team being able to iterate quickly on concept (i.e. what we wanna out of AS support).
• about 5x-10x smaller .wasm sizes on practice currently in prod. Which impacts both storage cost and execution cost because of .wasm compilation.

Note that both our docs:
https://docs.near.org/docs/roles/developer/contracts/near-sdk-rs and examples have solid stuff on Rust:
https://examples.near.org

So I don’t think we are biased towards AS. In fact we had to cancel NEAR Studio to accommodate Rust as main focus. Which according to @illia has negatively impacted engagement with web IDE.

But we had to do it because there is expectation that Rust going to be safer for use cases with a lot of money. It’s probably true though never was supported by strong data (e.g. nearcore had serious security issues despite using Rust) but by trust into maturity of language.

Rick Tobacco (user in our Telegram) wants to work on C++ SDK actually. We should definitely give grants for support as e.g. it might attract some EOS devs. Or generally people who want to start doing something new with C++ (SF WASM meetup had plenty of such folks).

Unfortunately C++ generally has similar issues as Rust:

• slow compilation speed
• large executable sizes
• not something most webdevs would want to use

Lua is super cool idea as a bounty as well if it’s fast enough – strong synergy with gamedev community. Won’t hurt for NFT adoption.

My 2 cents and a question for @dcode:

Is it possible to make AssemblyScript and Typescript more compatible?
I mean, is it possible to make AssemblyScript compile most of valid Typescript code to WASM?

If developers can use the same mechanism they’re using with Rust (i.e. test and debug on x86, leveraging rust tooling, but finally compile to WASM), it will make AssemblyScript way more valuable and powerful. I mean if I can use all the incredible powerful and ubiquitous Typescript & Javascript IDEs & debugging tools to debug a NEAR SC in written in “TS/AssemblyScript”, it makes AssemblyScript a much more valuable tool for NEAR and for any other WASM-based env.

I understand that there are pain-points for compatibility e.g. big integer management, u64, u128, u256, u8 arrays, but those are language design decisions that can be changed, for example devs in Solidity use a safe-integer library with methods like sub() add() mul() a-la LISP. This is ok and acceptable. We can manage big integers like that and make AS and TS compatible.

I understand that this means AS not being a “different language”, and becoming a “compile to WASM” option for TS, but I think that’s a good thing!

If changing the direction of AS is not possible, Can we make at least some “AS version/subset” that’s oriented to be: compilable, debuggable and executable in a TS/js environment, with all the highly powerful TS/js tools?

All these requests come from my experience with AS, mainly trying to write in AS the staking-pool rust core-contract. It was a frustrating experience. The same happened to me, I started writing TS only to find minor differences that prevent me from using all the TS/js powerful tools.

To clarify one point in my position: I’m against removing AssemblyScript from our docs and tooling. I tried to make the case for keeping AssemblyScript as a prominent feature of our developer onboarding experience. But I do support de-risking our roadmap by offloading ongoing AssemblyScript maintenance (and even expanding to other languages) to partners and community.

@nearmax – Regarding what you say here about “reverting for that research” …

nearmax:

The other issue, is that we have explicitly agreed as an organization to not call AssemblyScript TypeScript. It is unclear why this was reverted for that research.

I think you may have gotten the wrong impression about this. We were not referring to AssemblyScript as TypeScript during the research nor have we made that mistake since we agreed as a team almost a year ago to be explicit about AssemblyScript. For sure this is the case in anything I’ve been directly involved with. We can discuss offline if you prefer since this is out of scope here but I wanted to make this clear.

luciotato:

Is it possible to make AssemblyScript and Typescript more compatible?
I mean, is it possible to make AssemblyScript compile most of valid Typescript code to WASM?

There is certainly the desire to become (much) more compatible with TypeScript, and we will become better on that front with time, yet how far we can go with that (just yet) is limited. We could have built an interpreter instead for example that supports all of JS, but didn’t because we as a project are not interested in making an interpreter due to its performance and binary size characteristics. One could say that we are moving on a slippery slope here by design that’ll constantly get us in trouble, yet if we wouldn’t, it wouldn’t be AssemblyScript anymore.

Of course there’s a lot of stuff that can be improved today, and asking for more and better is always fine. Fronts we all can work on for example:

• Make sure that those features we already have work well, for example with more testing
• Implement more of the features that are viable today, just don’t get at each other’s throats over it
• Improve tooling, for example by highlighting problems as one types, or documentation, to better manage expectations

With every bit of improvement we’ll get closer to what more people consider most of.

This discussion has had parallel treads on various topics. I will address the following two questions:

1. Why should we support AS?
2. How should we support AS?

Why should we continue to support AS?

As @vgrichina pointed out Paras is already deployed to mainnet with AS. And @amgando pointed out that serious hackathon projects have used it. For all the flaws/immaturity that the language has we have done well to make the most of it from a DevX experience.

We now have:

• IDE support using TS, including inline documentation and go to declaration support (even on Github!)
• Unit test support which tests the contract in Wasm (unlike Rust).
• asbuild provides easy defaults for debug/release targets, and workspace support.
• Contract writing is done with little boilerplate or complicated build phase to handle (de)serialization on contract calls.

I admit that the improvements (especially the build process improvements) weren’t flushed down the pipeline and ended up missing from examples; for which I take full responsibility. However, compared to other smart contract platforms our DevX stands out. I’ve been told by some that the DevX of AS alone has attracted some partners.

At this point continued support isn’t as costly as starting fresh with another language and reaching the same level of DevX.

There is market demand

Regardless of specifics, it is clear that with one million TypeScript devs and millions more JavaScript devs it is foolish not to want to drive adoption of these devs to our platform. Microsoft might support a TS -> Wasm compiler, they’ve done something similar for targeting embedded devices, and we could consider supporting it. As for JS the costs of running an interpreted runtime make it infeasible. So in the time frame the next 6 months AS remains our best bet.

How should we support AS?

Roadmap for next six months:

1. Add coverage information for testing: This will allow us to have a metric for current coverage of stdlib testing and subsequent improvements. This can be very simple to start with just injecting block coverage. Partners writing in Rust have requested this feature as well.
2. Connect this coverage information to fuzzing tools. The bug found in the stdlib for string comparisons is a prime candidate for a type of bug found with fuzz testing.
3. Improve debugging support with DWARF, which Rust supports for debugging a Wasm, to allow for stepping through lines when debugging. This could also help with turning block coverage data into line coverage and help with Rust side too.

By focussing on these make concrete steps to improve safety and DevX at the same time. An alternative using individual bounties to solve these issues is to create a new grant initiatives to find teams which can work on broad high level goals removing my personal effort in the holding their hands. With some initial planning our part this roadmap is achievable in the next six months.

Some quick thoughts/heuristics with only a surface-level understanding of the tech aspects:

1. If devs want to deal with millions of dollars in their contracts and have done the work of learning Rust, why wouldn’t they (grudgingly) go through some additional difficulty in the build/test/deploy process? Seems like the “building super secure contracts” persona will not favor dev UX over that, so maybe the marginal value of investing more effort in rust, especially in our default flows, isn’t worth it. [this assumes the marginal future Rust dev effort is in UX-related stuff, but maybe it’s actually in deeper tech stuff and I didn’t catch that]
2. On the flip side, the highly iterative experimental dev archetype seems to value UX over security/precision. If the path to success in our community is about low barriers to entry and high iteration speed, this seems like the optimal place to put additional resources.
3. Speaking of resources, what opens up if we use abundance thinking? If there are things we can do in parallel (or with increasing speed) by applying additional financial resources or bringing in other teams, etc, that’s what grants are for. Obviously, we have to focus the docs and particularly the time of core team members, but if there’s anything we can expand/extend/improve outside of that, please do so!

Highly biased personal opinion: I’ve personally found Rust opaque and not worth the time to learn just hack around for a weekend to bring something to life, so I strongly relate to what Sherif described.

luciotato:

If changing the direction of AS is not possible, Can we make at least some “AS version/subset” that’s oriented to be: compilable, debuggable and executable in a TS/js environment, with all the highly powerful TS/js tools?

I think that’s kinda already a thing:
https://www.assemblyscript.org/portability.html#portable-stdlib

erik.near:

Speaking of resources, what opens up if we use abundance thinking? If there are things we can do in parallel (or with increasing speed) by applying additional financial resources or bringing in other teams, etc, that’s what grants are for.

Exactly, we are currently sitting on hundreds of millions of dollars and seriously discussing stuff like “should we continue having one employee working part time on the top used language for NEAR”.

What I’m imagining is the following:

• TS SC code that can be unit-tested, executed and debugged as ts/js (with vscode for example) and that can be later compiled to WASM

• A chain-simulator written in TS
  => You can debug step-by-step simulated multi-contract cross-contract-calls DApps using vscode
  That will be a large productivity boost, and the universe of ts/js programmers can write and debug step-by-step NEAR typescript/AS smart contracts calling each others with their current ts/js tools
  Show-off bonus: you can run a simulated chain in the browser.

@vgrichina

what kind of data do you need to show that AssemblyScript is valuable.

There are standard techniques on doing market research and A/B testing, I would start with them. I am however not familiar with market research, but off the top of my head we should be taking care of the following:

• Identifying the segment that we are addressing and making sure the selection method is not biased. Are web developers the only segment that we care about? If not are we are reaching out only to web developers when asking about contract language preference? Can @AlexTinsman or @sashahudzilin help us identify the user profile that we are targeting and ratios between front-end/back-end/mobile/blockchain developers that we are surveying? Given, the most recent changes in org strategy by @illia the survey should be targeting more existing blockchain developers as oppose to front-end developers;
• Identifying if there is a bias in how we are sourcing the data. GH matches are biased because AssemblyScript is set to default in create-near-app, third-parties default to AssemblyScript, etc;
• Identifying the null hypothesis. What are we comparing the survey results to? Are we comparing AssemblyScript preference to Rust, other general purpose languages, or to blockchain-specific languages? Did we run survey with exactly the same questions for these other languages?
• Identifying minimum number of people that need to be surveyed. What number is high enough to make results distinguishable from a statistical fluke? Consider this survey. p=0.419 chose Rust over JS-like languages.stdev=sqrt(p(1-p)/(n+3)), where n=248, which means 2-sigma is 0.06. If we had less than 100 people replying to this survey instead, it wouldn’t have been statistically significant;
• We need to actually have quantitative data;

• deep UX research from @corwinharrell and @amgando showing users prefer AssemblyScript and don’t have good understanding why would they use Rust instead

This research is not actionable, because it does not present any quantitative data. We had similar researches done by me and @frol during hackathon that showed strong preference of Rust over AssemblyScript. We even had collected numbers and extensive feedback.

having 200m locked in smart contract would be good example, maybe we need to make it more clear

• about 5x-10x smaller .wasm sizes on practice currently in prod. Which impacts both storage cost and execution cost because of .wasm compilation.

To clarify, this explains your personal preference, but it is not a market research.

So I don’t think we are biased towards AS.

We have bias towards AS because:

• Guided walkthroughs use AS;
• Third-party tutorials use AS;
• create-near-app defaults to AS;
• We have put dedicated effort into polishing AS tutorials which we haven’t done for Rust.

It’s probably true though never was supported by strong data (e.g. nearcore had serious security issues despite using Rust) but by trust into maturity of language.

Again, issue in language compiler or STD is not the same as issue in user code. Rust is more safe than AS, because Rust has stable Rust->Wasm compiler, while AS->Wasm is not stable. Plus there is a whole bunch of large organizations like Google and Mozilla that put their money or Rust being safe by using it in their core products. Let me re-post the criteria for the language compiler+STD to be considered stable:

• Social approval. Large organizations put their money on it by using it in their core products;
• Self-approval. The compiler+STD is classified as stable by their own core developers;

So far, the above is satisfied for Rust but is not satisfied for AssemblyScript.

Unfortunately C++ generally has similar issues as Rust: slow compilation speed

We still don’t have any quantitative data to support the argument that compilation time is an issue.

Unfortunately C++ generally has similar issues as Rust: not something most webdevs would want to use

I am not sure we have agreed that web developers is our primary market in short or medium term.

@luciotato I agree there are only advantages in making AS more compatible with TS. You are also far not alone with having frustrating experience with trying to write TS only to find out TS != AS.

@amgando

To clarify one point in my position: I’m against removing AssemblyScript from our docs and tooling.

Is there a reason why we don’t have a switch in http://docs.near.org/ that allows users to switch all documentation to Rust or AssemblyScript view?

I think you may have gotten the wrong impression about this. We were not referring to AssemblyScript as TypeScript during the research nor have we made that mistake since we agreed as a team almost a year ago to be explicit about AssemblyScript.

The question in the research states:

Given the option of writing smart contracts in TypeScript/AssemblyScript or Rust, which would you prefer currently, and why?

It conflates TypeScript and AssemblyScript as if it is one entity.

@dcode AssemblyScript lacks the variety of libraries available for other languages which is one of the main reasons our users choose Rust over AssemblyScript. It would be very helpful if you could write a TypeScript->AssemblyScript transpiler that would do its best to remove manual effort of converting TypeScript libraries into AssemblyScript. Would you supervise this project if it was funded?

@willemneal

• IDE support using TS, including inline documentation and go to declaration support (even on Github!)

I am not sure what you are referring to.

At this point continued support isn’t as costly as starting fresh with another language and reaching the same level of DevX.

Our decision should not be influenced by the Sunk Cost Fallacy.

Regardless of specifics, it is clear that with one million TypeScript devs and millions more JavaScript devs it is foolish not to want to drive adoption of these devs to our platform. Microsoft might support a TS → Wasm compiler, they’ve done something similar for targeting embedded devices, and we could consider supporting it. As for JS the costs of running an interpreted runtime make it infeasible. So in the time frame the next 6 months AS remains our best bet.

As I explain below to @erik.near here are non-financial costs to supporting multiple languages. Also, as I explained above we haven’t decided whether we want to target web developers as our primary market in the next 6 months.

Roadmap for next six months:

To clarify, we don’t have any evidence that fuzzing tools would produce significant value to people writing contracts. However, we have expert opinions of it being overvalued in this specific scenario of using it for AssemblyScript contracts. Fuzz testing is similar formal verification – everyone talks about it, it sounds nice in theory, it makes us feel safe, but it is not as efficient as improving test coverage by writing tests manually.

With some initial planning our part this roadmap is achievable in the next six months.

What is the expected impact of this initiative? How much closer this will bring us to stable AssemblyScript compiler?

@erik.near

1. If devs want to deal with millions of dollars in their contracts and have done the work of learning Rust, why wouldn’t they (grudgingly) go through some additional difficulty in the build/test/deploy process? Seems like the “building super secure contracts” persona will not favor dev UX over that, so maybe the marginal value of investing more effort in rust, especially in our default flows, isn’t worth it. [this assumes the marginal future Rust dev effort is in UX-related stuff, but maybe it’s actually in deeper tech stuff and I didn’t catch that]

I partially agree, the marginal value of improving Rust DevX now is lower compared to when we were improving Rust DevX in the early days.

On the flip side, the highly iterative experimental dev archetype seems to value UX over security/precision. If the path to success in our community is about low barriers to entry and high iteration speed, this seems like the optimal place to put additional resources.

That’s true, what this archetype does not realize is that they can only enjoy good DevX if safety is guaranteed. I am not sure people would be able to enjoy MacOS same as much if it was riddled with viruses and exploits.

1. Speaking of resources, what opens up if we use abundance thinking? If there are things we can do in parallel (or with increasing speed) by applying additional financial resources or bringing in other teams, etc, that’s what grants are for. Obviously, we have to focus the docs and particularly the time of core team members, but if there’s anything we can expand/extend/improve outside of that, please do so!

Reposting my answer to @erik.near here:

It sounds that you are describing Option 3. We can even do it for other languages and not just AssemblyScript and Rust. The reason why we need to have a discussion is because supporting language comes at other costs that are not financial:

• Distractions to the horizontal teams, like: Berrypickers, DevRel and whoever writes documentation, Partner Relations, etc;
• Potential reputation hit if we support something that later turns out buggy our with security vulnerabilities.

Also, stable compiler requires a scale of support that only large organization like Mozilla or Google can offer.

This is actually a good idea to write NEAR Runtime in TS to allow full end-to-end debugging of with AS contracts executed as TS. CC @mikedotexe @evgenykuzyakov We might consider writing some components of NEAR core in TS or AS to allow execution in browser too along side near-api-js.

The decision

The decision is to go with the modified Option 3. NEAR will create a separate grant for AssemblyScript that will capture two aspects:

• Development of NEAR-specific AssemblyScript tools and documentation;
• Improvements to the AssemblyScript ecosystem (libraries, STD, compiler).

How much of the grant will be spend on the second bullet point will depend on the degree of support by the core AssemblyScript team (CC @dcode).

The team using this grant will be external to NEAR and internally NEAR will not budget time for AssemblyScript. Specifically, the product team (CC @kendall), Berry Pickers (CC @mikedotexe) , Contract Runtime (CC @olonho) and any other teams are not expected to work on AssemblyScript.

The next steps are the following:

• NEAR will work on composing the grant proposal and communicate with core AssemblyScript team on how much they want to be involved;
• Potentially, NEAR will supervise assembling the team to work on the proposal, potentially with the help of the core AssemblyScript team.

I’m afraid, you misunderstand the situation. You are essentially asking me repeatedly, the only person you have the counterweight of a third of a real job leverage on through your sponsorship, to drop everything like getting GC or other fundamentals right (also for you) to work on I-don’t-known-what now because you say so. I can only wonder about this sentiment, as it isn’t really supporting us anymore but rather sabotaging us. It’s almost funny, as you seem to sit on millions there while keeping the open source tech you rely on on a short leash in an absurd attempt to inflict influence on them. If that’s the price I have to pay for a healthy life, I suggest you take your 2k dollars and see how far this gets you elsewhere. In fact, not having to worry about this anymore may even help us more than constantly being on the brink of becoming defunded over whatever non-technical reasons. At least we can live and work in peace then.

We did have this here: GitHub - nearprotocol/near-runtime-ts: Typescript library for writing near smart contracts which looks like it’s been archived and links to near-sdk-as. In terms of priorities, I’m making a note of this, but feel that our Q1 OKRs are already ambitious as-is. I don’t feel comfortable bringing this into our team’s priorities in the short term.

@dcode I am not sure you understand the decision correctly. Also, I am not sure what is your interpretation of it. Let me re-state it differently here, since I think this new option is strictly better for AssemblyScript as a project than the current support that NEAR is offering.

• We want to create a separate grant and have a separate team paid by this grant to work on AssemblyScript for us. This separate team is going to be separate from the NEAR team and the AssemblyScript core team;
• The grant will pay for two areas of development: NEAR-specific devtools and AssemblyScript core development, compiler/std/etc;
• However, NEAR does not have enough expertise to:
  • Identify what important areas of AssemblyScript compiler/std/etc need to be developed and how to push it closer to stable. In other words, we need someone who would tell them what to work on and set their priorities;
  • Assemble this group of people to work on this grant, since we might be lacking ability to screen them on a subject of how fitting their skillset is for working on AssemblyScript compiler/std/etc. In other words, we need someone to say: “Alice, Bob, and Carol seem to be skilled enough to contribute meaningful work to AssemblyScript compilers/std”;
• It would be great if someone from AssemblyScript core team could help us with the above points, especially since AssemblyScript core team would have to review the code contributions to the compiler and std anyway, so they might as well set the work items in the first place. However, we understand that AssemblyScript core team has limited capacity, so depending on how much capacity they can offer this separate AssemblyScript team will spend more or less time on contributing to AssemblyScript compiler, std, and libraries. It would be great if we could discuss how much capacity AssemblyScript core team can offer when we write the grant proposal, so that we outline the scope of work in the grant correctly;
• I haven’t mentioned the 2k USD/month contributions in the above post, but I didn’t mean to imply that we are stopping the contributions.

So there are two paths:

• AssemblyScript core team is willing to help us assemble the team for the grant (maybe you have some people that you can refer?), help this team identify the work items for contributions to AssemblyScript compiler/std/etc, and help review their PRs. In this case we will include contributions to AssemblyScript compiler/std/etc into the grant, also the scope of work on AssemblyScript compiler/std/etc will depend on how much time AssemblyScript core team will be able to contribute;
• AssemblyScript core team does not have capacity to help. Then our grant proposal will most likely focus on NEAR AssemblyScript devtools only.

I hope it clarified the misunderstanding. WDYT? Would you or anyone in AssemblyScript core team will be willing to help us?

Sorry for moving late on this. I was trying to move this conversation forward with people in the community, and they were responding outside of this timeline. I think we shouldn’t blow away all examples. I think finding a community owner is fine though.

There is also some new confounding circumstances from a non-technical angle:

1. Haseeb Qureshi wrote a glowing review of NEAR and one of the core principles is the fact that you can write the contracts in a simple js-adjacent language. Dragonfly + NEAR. Today, we’re thrilled to announce… | by Haseeb Qureshi | Dragonfly Research | Jan, 2021 | Medium

2. I asked Aaron Turner for feedback and he made some great points that AssemblyScript unblocked folks who did not wish to learn Rust. It allowed people to be more productive because it was closer to the thing they were comfortable with. (Aaron, if you’re uncomfortable with me sharing this portion, I will remove it. Please let me know!)

Furthermore, from the developers in the ecosystem who have used AssemblyScript to onboard, they found it mostly delightful. Even with the warts. I don’t see a problem with a public and supported member of our community owning this, but I don’t think scorched earth in our docs, tutorials, examples and codebase is the best way forward.

@potatodepaulo

Thanks for the feedback.

We are not removing it from docs or devtools. We are externalizing development through a grant for a third-party team (not to be confused with AssemblyScript core team) and giving it more resources, since right now it is mostly @willemneal who is working on AssemblyScript a small fraction of his time.

nearmax:

There are standard techniques on doing market research and A/B testing

nearmax:

We still don’t have any quantitative data to support the argument that compilation time is an issue.

Doing proper A/B test would take a longer time than was dedicated to making a decision here.
In any case I think we can actually do A/B tests on near.dev (e.g. using Netlify’s built-in tooling) testing these hypothesis:

• AssemblyScript is better than Rust in onboarding (expected result: larger success rate as in “deployed app and made transaction” on gitpod)
• smaller compilation time results in larger success rate (currently near.dev pre-compiles Rust examples, we can compare success rate)
• lower success rate if showing only Rust examples

nearmax:

having 200m locked in smart contract would be good example, maybe we need to make it more clear

• about 5x-10x smaller .wasm sizes on practice currently in prod. Which impacts both storage cost and execution cost because of .wasm compilation.

To clarify, this explains your personal preference, but it is not a market research.

@nearmax we have countless users complaining all over the public channels about 35 NEAR locked in wallet for 2FA. Mintbase is concerned about their contract size posing similar challenge to their business model as well. This is about money and winning business, not about my personal preference.

If users disable 2FA because it’s too expensive (one of the top customer support requests right now) – it doesn’t help security of our system.

nearmax:

Is there a reason why we don’t have a switch in http://docs.near.org/ that allows users to switch all documentation to Rust or AssemblyScript view?

That would be best solution from my POV as well, especially if WebAssembly future delivers multi-language ecosystem

We also can then also A/B test this easily by changing default.

nearmax:

I am not sure we have agreed that web developers is our primary market in short or medium term.

De-facto our highest volume third-party project currently live on mainnet is done by web devs (Paras). I am not sure what is value framework we use to decide that our existing well-performing customers aren’t our short-term/medium-term market. Defi projects that are blocked on something that is near, but not here (bridge, EVM) cannot be considered our primary market before we unblock them.

Here’s a screenshot with an example why:

photo_2021-01-19 15.52.53964×120 13.6 KB

We’ve already been doing this for a while to our partners (notice a year in the message date) and it is generally far more damaging to our reputation (as it already has happened) vs security issues (that might happen in future).

I’d say Paras early success is super critical for other reason as well – it opens door for far more creative crowd joining our community and becoming active contributors. I’ve dealt a lot with existing speculator-driven community of wallet users and it’s really doesn’t often go above “wallet is shit” level of contribution. Especially when price is going down. This also independently experienced by Andre Cronje (YFI), check out this post on his experience with Defi-incentived community bulding:

Building in defi sucks (part 2)

It has been almost a year since the first time I wrote these words. Any industry has its good and its bad. You leave an industry when the…

Reading time: 5 min read

P.S. I am not sure I understand decision framework. AFAIK everyone except @olonho and you in this thread who provided input was pro continuing AssemblyScript support. Quite a few external people are somewhat concerned about Rust as well:
https://twitter.com/mattlovan/status/1351332697923231745?s=20
https://twitter.com/DennisonBertram/status/1351381039919345664?s=20
https://twitter.com/mzavershynskyi/status/1341590222904037378 (replies to your survey)

Hello! Just wanted to also chime in. I haven’t said anything so far, just because by the time I saw the thread, a lot of the main points I was going to bring up, were already said by various people in this thread so far. So thank you to everyone for such an awesome discussion!

I wanted to also add a little more context on my chat with @potatodepaulo

potatodepaulo:

I asked Aaron Turner for feedback and he made some great points that AssemblyScript unblocked folks who did not wish to learn Rust. It allowed people to be more productive because it was closer to the thing they were comfortable with. (Aaron, if you’re uncomfortable with me sharing this portion, I will remove it. Please let me know!)

So I picked out some of the points I can share here that I brought up in our chat. With the huge caveat, these are all my opinions, and I am not speaking from my employment / team’s standpoint, but rather a member of the community. These are all my opinons, and experiences. Take it with a grain of salt, but they are based on my experiences if that makes sense .

I’m on a team working on a platform that has SDKs that rely on WebAssembly, in particular Rust and AssemblyScript (Which is similar to the NEAR use case! )

In my opinion from what I’ve seen, our really large potential developers use Rust. Because they either need a language feature, or need missing library. Like for example, a customer want’s to use some large, but common, image library that would be in a more mature language ecosystem.

However, like 2 / 3rds of our potential developers wont touch Rust, because it’s not familiar to them or their team, they can’t get past the learning curve, etc…

AssemblyScript has been great for getting that 2 / 3rds of developers through the door and try things. Then after trying our platform with AssemblyScript, they either: A. Decide to just wait for another, closer to JS language, B. Decide to switch to rust after they build their Proof of concept in AS, or C. AssemblyScript did enough of what they needed and just deploy that to prod.

We’ve had all of these cases (A, B, and C) happen at a mostly equal amount

And! There is another case of a lot of internal folks, do not want to learn Rust, or have tried to learn Rust over a long period of time and it’s just not for them. Having a second, and JS-like, language for them, really unblocked a lot of engineers internally. And AssemblyScript is now great for all kinds of small internal tools here and there.

In general, I am biased being a team member on the AS team, to say stick with great support for AS haha! But, I don’t know the full situation at NEAR to give good advice.

In response to the general feeling I get from the thread and things: AssemblyScript is great for onboarding, and getting people to give your platform a try. And sometimes it’s not always the most positive experience since AS and Wasm are so young. But more importantly, there is a large crowd of people, and use cases, that AssemblyScript is the right answer for, today. And I definitely feel like the pros outweigh the cons, from both an AS team member, and someone who works on a platform who supports both Rust and AS.

No, I don’t want me or anyone else on the AS team to be unjustly pressured like this by NEAR management anymore. Not the first time this has happened. AssemblyScript is an open source project of technical people, one funded, with little sense for this kind of behavior. Given how matters have unfolded here once more, and that the same is scheduled to repeat every six months, with a sword of Damocles hanging over our heads in between, I am at the point now where I can only ignore anything just remotely smelling like toxicity. I, and I am sure others on the AS team do as well, will always appreciate to talk to fellow technical people in the NEAR organization who just want to build exciting things together, but this stuff, no, not anymore. I sincerely hope that you are not treating your own people this way.

@dcode I sincerely don’t understand what you are talking about. We offered to allocate a portion of funds to contribute to AssemblyScript core development, and let AssemblyScript core team decide how to use it, without our supervision, whether you want it to be spent on GC, self-hosting compiler, STD coverage, etc. As I said we don’t have expertise do decide what is the most efficient way to push AssemblyScript compiler closer to stable. Assembling an independent team to take this grant is simply how we usually do grants, but it does not have to be this way, we can also allocate this one time funds package directly to AssemblyScript core team and let you decide whether you are going to hire more people or sponsor existing people. I am not sure I understand what is the risk here for you.

I am not concerned with the decision at all. I am fine with whatever you decide for your own reasons, and though I may not understand your decision framework, it’s not my business and I have no right to criticize that.

My replies are solely referring to how we have been framed repeatedly. I could make quite a list of similar things I did not agree with, but the primary reason for me to take a stand now is that you are strictly binding your support to how much you can exploit an open source project that is already working very hard by yet again carefully constructing a situation of fear, uncertainty and doubt with statistically completely ridiculous Twitter polls, general biased wording and whatnot. On that basis, everything you have proposed earlier involved me, or AS as a project, essentially becoming a cheap, if not free, labor force for you, in addition to what we already do, in some scenarios even doing what should be your job, with the alternative layed out here in all facets being to reduce support.

All I really say here is “no” to this kind of exploitation, even if I have to risk your sponsorship for that.

dcode:

On that basis, everything you have proposed earlier involved me, or AS as a project, essentially becoming a cheap, if not free, labor force for you, in addition to what we already do, in some scenarios even doing what should be your job, with the alternative layed out here in all facets being to reduce support.

I can kinda see how you arrived to this conclusion, but I think you are taking interpretation to an extreme. We offer you more resources to use using your own judgement without attachment or repercussions. What I said is that depending on how much guidance you can offer us we will give less or more extra resources. I think it is logical that we don’t want to allocate a large financial package and not have anyone help us to make sure it is used efficiently, e.g. by you telling how much of this package goes into GC, how much of it goes into STD coverage, and how much of it goes into other core AssemblyScript development. I don’t think it is morally wrong when someone gives an OSS project a financial package that this OSS project promises to oversee efficient usage of this resource. I also don’t think it is morally wrong to express a preference on how this package should be used, e.g. “Please use it to improve stability of AssemblyScript compiler”. Also, from your side, I don’t think it is wrong to give us a push back if you think our influence is somehow creeping into internal affairs of the AssemblyScript core team, I just wish you used a different language.

@nearmax For a complete picture and as a member of the AssemblyScript Core Team, I think I should speak the same way.

To begin with, I still don’t understand what you are trying to achieve. Web developers are no longer your TA, as I understand it? And is this just a shift in focus to experianced Rust system developers?
Or is it because you think AssemblyScript is not stable and mature enough in you opinion? Why was this question raised only now after 2 years of usage? Why this not problem for The Graph for example which use very outdated version of AssemblyScript?

About grants and what we need to put together a team. Max you already somehow asked me about it, and I found people interested in this and sent you their CVs. You haven’t even contacted them! Then it put me in a very awkward position! Are you really interested in this? Or is it just a tactical step to say “well, we tried it and nothing happened”.

Besides AssemblyScript I maintain an as-bignum library that your AS SDK dependent on. And now I do it absolutely for free. I’m not complaining, I just want to note that you are the only user of this lib and I am doing this exclusively for you now=)

If you really want to help us, then just leave it as it is and stop imposing your support in the form of grants. Grants/airdrops/gitcoin tasks may work in the crypto community and the academic community, but in a community of engineers who work non-stop for years day by day, stability and concern about every little matter is much more important. Thank you for understanding.

MaxGraey:

Besides AssemblyScript I maintain an as-bignum library that your AS SDK dependent on. And now I do it absolutely for free. I’m not complaining, I just want to note that you are the only user of this lib and I am doing this exclusively for you now=)

Please understand our perspective as well. We are basically offering you money to do it, hire more people, etc. But we want commitment to some goals.

Like I would literally offer you to have a bounty to get e.g. this done: Implement 128-bit types necessary for NEAR blockchain runtime · Issue #35 · MaxGraey/as-bignum · GitHub. You responded by fixing part of this stuff for free. But what I actually want is 100% of this done. And I don’t mean for that specific budget, can be a different one. What would be a good way to get it done from your perspective if not bounties?

MaxGraey:

To begin with, I still don’t understand what you are trying to achieve. Web developers are no longer your TA, as I understand it? And is this just a shift in focus to experianced Rust system developers?

This is mostly specific to what @nearmax team focuses on. Different NEAR community members want different stuff.

@MaxGraey Thanks for chiming in.

To begin with, I still don’t understand what you are trying to achieve. Web developers are no longer your TA, as I understand it? And is this just a shift in focus to experianced Rust system developers?

When I said:

Given, the most recent changes in org strategy by @illia the survey should be targeting more existing blockchain developers as oppose to front-end developers;

I did not imply that we will not be targeting web developers or other languages besides Rust. What I meant in that reply to @vgrichina is that if we do market research we should state clearly what is our target audience, or what is the target distribution if we have a mix of audiences.

Or is it because you think AssemblyScript is not stable and mature enough in you opinion?

I don’t think it is mature, because it does not satisfy the criteria that I mentioned before:

Let me re-post the criteria for the language compiler+STD to be considered stable:

• Social approval. Large organizations put their money on it by using it in their core products;
• Self-approval. The compiler+STD is classified as stable by their own core developers;

Why was this question raised only now after 2 years of usage?

I believe it was raised multiple times before, but I don’t think I have hard evidence of this happening.

Why this not problem for The Graph for example which use very outdated version of AssemblyScript?

I am not entirely knowledgable about The Graph security model and their safety tolerance. From what I can tell, they are using AssemblyScript for querying data, while we are using AssemblyScript for contracts. The consequence of having a buggy contract on a blockchain is that someone can exploit it to extract assets or make it lose assets. Also the contracts are frequently immutable meaning once you compile it with one AssemblyScript compiler version and deployed it you cannot recompile it later. The consequence of having a buggy data query is that you have wrong data. It can still be pretty bad, depending on how it is used, similarly to buggy SQL query, but not as bad as with the contract.

About grants and what we need to put together a team. Max you already somehow asked me about it, and I found people interested in this and sent you their VCs. You haven’t even contacted them! Then it put me in a very awkward position!

It did indeed happen 1.5 years ago and on behalf of the organization I am very sorry for it. Back then we were much smaller and less organized, so things slipped. When I found out about it from you I tried to fix it as you might remember.

Are you really interested in this?

We are going to look for people whom we can contract to work on AssemblyScript for ~6 months. We will follow up with you once we have clarity, I don’t want us to put you in uncomfortable situation again, sorry. CC @potatodepaulo

Or is it just a tactical step to say “well, we tried it and nothing happened”.

If we had this intention I wouldn’t have started this thread.

Besides AssemblyScript I maintain an as-bignum library that your AS SDK dependent on. And now I do it absolutely for free. I’m not complaining, I just want to note that you are the only user of this lib and I am doing this exclusively for you now=)

Sounds like a great opportunity to give you some funds to do more of that and help you contribute to more core AssemblyScript libraries, now that we have decided to put more resources into AssemblyScript development.

If you really want to help us, then just leave it as it is and stop imposing your support in the form of grants. Grants/airdrops/gitcoin tasks may work in the crypto community and the academic community, but in a community of engineers who work non-stop for years day by day, stability and concern about every little matter is much more important. Thank you for understanding.

Suppose we give you a batch of NEAR tokens to do AssemblyScript core development, without attachments or supervision. They are liquid, meaning you can convert them instantaneously to BTC on http://binance.com/ or any other exchange, and then cash out into your local currency, wherever you are located geographically. Are you saying that you will not use it?

nearmax:

The consequence of having a buggy data query is that you have wrong data. It can still be pretty bad, depending on how it is used, similarly to buggy SQL query, but not as bad as with the contract.

on practice stuff like query layers, oracles, etc also have about as huge impact as bugs in smart contracts, like see e.g. this on 100m liquidation caused by Coinbase Oracle troubles:

Seeming oracle attack causes $100m in Ethereum DeFi liquidations

It appears we just saw our latest DeFi exploit/attack, but this one was much different than all the rest. Bitcoin, Ethereum, and the rest of the crypto market spiked dramatically lower on Wednesday evening as buying pressure finally abated. The...

Est. reading time: 2 minutes

@torch2424 thanks for chiming in.

I think everyone in this thread, including myself, agrees with you that AssemblyScript is valuable. A lot of confusion came from me debating with @vgrichina and other NEAR members on whether we have any unbiased quantitative data on how much AssemblyScript is valuable.

Your data on Fastly, even though approximate, is invaluable to us. It helps us see that if we have approximately the same target audience as you, then AssemblyScript can be as valuable as Rust, or even more valuable. I wish there was a blog post with stats that we could dig in. If we had this kind of data at the beginning of this discussion then I think the discussion might have been much shorter.

nearmax:

thanks for chiming in.

You are welcome!

nearmax:

I think everyone in this thread, including myself, agrees with you that AssemblyScript is valuable. A lot of confusion came from me debating with @vgrichina and other NEAR members on whether we have any unbiased quantitative data on how much AssemblyScript is valuable.

Ah! I didn’t know y’all were having that debate. I’ve been essentially been leading Devrel on AssemblyScript for a few years now, and have worked with a lot of people using AssemblyScript and consciously I look for patterns on these types of things. If y’all were having these discussions and wanted some clarity, I totally could have helped earlier on. Feel free to reach out anytime. Of course I’m biased as well, but, I try my best not to be.

nearmax:

Your data on Fastly, even though approximate, is invaluable to us. It helps us see that if we have approximately the same target audience as you, then AssemblyScript can be as valuable as Rust, or even more valuable. I wish there was a blog post with stats that we could dig in. If we had this kind of data at the beginning of this discussion then I think the discussion might have been much shorter.

Glad it could be helpful! I will admit I’m a bit wary on things on what I can, and can’t say especially in a public setting.

So, as with the blog post you linked, Fastly only recently announced official support. In my opinion, There’s still so much more to do I don’t think we’re really prioritizing sharing data publicly.

Though, I’ll also add, even though we are both building similar things (Wasm SDKs), our organizations probably have different short-term goals, long-term goals, motivations, etc…

Which is another reason why I haven’t chimed in as much, as the question really requires sooooo much more context. And I definitely felt like others in this thread had much more context, than me, to make a really important community decision.

And I’ll also follow along with the other members team, take a step back, and chime in a bit

And just as an aside. I was going to mention this earlier and then forgot in my last reply. But I think a lot of the frustration here, is a case of “Wanting to have your cake, and eat it too”.

The future of WebAssembly, in general, is promising fulfill this metaphor. But it’s a long long way out. Some languages were able to fill in the gaps with their tooling (like Rust and C), but there is still still a ton of ground to cover in every ecosystem, including Rust and C. And a loooooooooot of ground to cover in other languages as well when you start thinking about Go, and interpreted languages running in Wasm (Python, JS, etc…). Which isn’t a bad thing, it’s just WebAssembly is very new!

For context, I’m not trying to deflect any maturity issues of AssemblyScript, as only WebAssembly maturity issues. While, I do think, as AssemblyScript being the earliest, and built-from-the-ground-up “WebAssembly first language” that out Maturity issues are to some degree tied to WebAssembly issues. Like for example, we’re all kind of in a tough spot in terms of code sharing until we get Interface types, we’re still catching up in performance with Threads and SIMD (which are only available in select runtimes), and Wasm Imports is really going to complete our security story. There’s gaps in the platform that all of us our building our tooling on. Sometimes these gaps can be solved by having a talented, large team, sometimes they can be solved with more funding or a larger budget, and some of them can’t because it’s just a lot of hard work that takes time to get things right. (Though, as a quick aside, comparatively, AssemblyScript is a little extra disadvantaged here as the team is small, and our current budget only goes to a single core team member as it’s just barely enough to make a comfortable living off of (Which after being a part of the project since the beginning has made a HUGE difference in how fast the project grows, and made it a healthier communitty overall). But again, to “catch up” it’s going to take a mix of budget, team size, and no matter what: time ).

All in all, choosing to build an SDK on top of WebAssembly, no matter the language or ecosystem, or tooling etc… is going to have a lot of cons, especially if you compare it to almost anything else out there that’s been around longer than WebAssembly. It’s honestly quite amazing how far we’ve come already in tooling for WebAssembly, but now we’re in the phase of getting all of the hard, real, time-consuming work done. Both in AssemblyScript, but again, as an industry trying to grow WebAssembly as a whole.

Suppose we give you a batch of NEAR tokens to do AssemblyScript core development, without attachments or supervision. They are liquid, meaning you can convert them instantaneously to BTC on http://binance.com/ or any other exchange, and then cash out into your local currency, wherever you are located geographically. Are you saying that you will not use it?

Not everyone is a blockchain person, and in some countries there are tax implications not everyone is knowledgeable about. You may be leaving a lot of potential to attract more smart people on the table by offering them tokens in return for their time.

Also, from your side, I don’t think it is wrong to give us a push back if you think our influence is somehow creeping into internal affairs of the AssemblyScript core team, I just wish you used a different language.

I typically regret getting into discussions like these eventually. Just a simple guy building compilers, chronically overworked and deeply caring about the project and that is treated fairly. Sorry for the language.

Suppose we give you a batch of NEAR tokens to do AssemblyScript core development, without attachments or supervision. They are liquid, meaning you can convert them instantaneously to BTC on http://binance.com/ or any other exchange, and then cash out into your local currency, wherever you are located geographically. Are you saying that you will not use it?

It so happened that I worked in the banking sector for a while, and then I had a chance to work in crypto several times. So knowing these two worlds from the inside, I trust banks and SWIFT transfers much more =) At least there is always an option to promptly cancel the transaction, there are guarantees. In 2020, in my country (you know), FATF adjustments and recommendations were adopted, you need to go through KYK and explain each transaction above ~$1000, otherwise you will be interested in fin. monitoring. This is no better and often worse than dealing with the banks) Or turn everything on illegal exchangers and hope that everything will be fine.

Personally I’m not a crypto enthusiast from the word at all=) And this is not the first time when we are offered payment with some own tokens. We even often joke that it’s time for us to issue our own cryptocurrency and start paying with all of it. And those who refuse will be blamed for short views and conservatism=)

@dcode @MaxGraey so I’m not sure I understand it right. Do you mean that you’d rather not receive any money at all than receive money but have to pay a bit more in taxes than usual?

vlad:

I would literally offer you to have a bounty to get e.g. this done: Implement 128-bit types necessary for NEAR blockchain runtime · Issue #35 · MaxGraey/as-bignum · GitHub . You responded by fixing part of this stuff for free. But what I actually want is 100% of this done. And I don’t mean for that specific budget, can be a different one. What would be a good way to get it done from your perspective if not bounties?

I’d really still want to hear what is the best way to get this done from your POV. Like e.g. we can pay somebody else to make a PR if you don’t want to take bounty money. But then you will have a burden of reviewing it, etc. We definitely don’t want you to get into situation where you have to support our work for free.

MaxGraey:

At least there is always an option to promptly cancel the transaction, there are guarantees.

I understand why this is good for somebody who sends money. But how this is good for somebody receiving money?

I understand why this is good for somebody who sends money. But how this is good for somebody receiving money?

I meant this not for a specific case, but in a general case.

You should also not write off SWIFT as a system that is not able to keep up with the times. SWIFT is currently experimenting with Hyperledger. The main problem with cryptocurrencies is its legalization and reputation. SWIFT has never had a problem with this for over 40 years. Therefore, there is trust from both banks and users. Otherwise, it doesn’t matter, my main thesis is that this does not suit me personally, since at any stage such as receiving, storing, converting to fiat, I can potentially lose all funds. At the same time, they can still refuse to receive or freeze my wallet on the exchange. So what are the benefits? Small commission? But are there a lot of risks? I don’t transfer gigantic amounts so 0,2-1,5% fee is ok for me (especially due to withdrawing of cryptocurrency in my country I should pay 2-5% fees usually), reliability and hassle-freeness are more important to me. Just as the security of smart contracts is important to you)

In general, I would not like the focus of the discussion to be mixed in the direction of SWIFT vs Сrypto or Rust vs AssemblyScript. That’s the whole problem in my opinion! Why can’t you support both?

I’m not sure I understand it right. Do you mean that you’d rather not receive any money at all than receive money but have to pay a bit more in taxes than usual?

Isn’t about paying taxes, but about dealing with them in addition to dealing with the blockchain parts. Getting this all right may easily become a full-time job with many pitfalls, and someone on our team would have to do it. In contrast, OpenCollective helps us deal with funds not only transparently (sponsors and individuals can see where funds go), but also manages tax details between the US, where our fiscal host is based, and an individual’s country of residence for us. They essentially have this all automated, and have a dedicated support team for anything else.

I’d really still want to hear what is the best way to get this done from your POV.

I think OpenCollective is a great way to manage funding of open source projects like AS. Sponsors can safely sponsor to a US-based entity and people from all around the world can submit a reimbursement or expense, and we’d either “Approve” or “Decline” it. No dealing with blockchain, no dealing with taxes for those distributing funds (recipients of funds do what’s mandatory in their own country, e.g. filling out a W-8BEN and do their personal taxes). Safe for everyone involved.

Say we had the funds on our OpenCollective, we could fund people either for doing full-time work that I can direct (there are people on our team I’d like to get on board) or issue grants for one-time projects to whoever wants to work on it. The funds would be there an everyone can be certain to receive their fair share without having to worry.

I may be missing a downside to this approach, of course. If so, let me know. For instance, we chose a US-based fiscal host to make this straight-forward for sponsors, who we anticipated to be US-based typically, but it may not be equally easy for non-US-based sponsors, not sure. Certainly still involves a base level of trust, yet it’s all transparent and I am certain we can find solutions in case of disagreement.

vlad:

I’d really still want to hear what is the best way to get this done from your POV. Like e.g. we can pay somebody else to make a PR if you don’t want to take bounty money. But then you will have a burden of reviewing it, etc. We definitely don’t want you to get into situation where you have to support our work for free.

Stable financing through open, safe and transparent platforms. That already works for all of us.

In my opinion, it is obvious that complex engineering tasks cannot be entrusted to bug bounty sites like GitCoin. This does not work! Here’s a simple example:

feat: String interpolation

AssemblyScript:main ← developerfred:issue/201

opened 07:09PM - 04 Aug 20 UTC

developerfred

+9983 -1195

Let’s extract the discussion on exact means of financing into a separate channel, if necessary.

Moving the discussion on the content of the grant here: AssemblyScript grant proposal discussion

MaxGraey:

That already works for all of us.

It doesn’t work very well for us however as we cannot get stuff done. Like e.g. this issue is open for 2 years already Support template literals · Issue #466 · AssemblyScript/assemblyscript · GitHub

I understand that this issue might not be your priority. Which is ok. However we need to make it someone’s priority and get it done. How can we achieve that in a way that is good both for you and for us?

Data Point: One of the projects attempting to port to NEAR has been struggling to find a Rust Dev for a while, and when I informed them about AssemblyScript today they were very excited because they already have JavaScript engineers.

Just a single data point, but they are now investigating if they can build on AssemblyScript instead of remaining blocked on not having a Rust Engineer.

I have a Rust dev available, we recently finished a project integrating diadata oracles into NEAR, here: GitHub - Narwallets/dia-sc: Dia gateway smart contract

what is you telegram, I will connect you

telelgram: Telegram: Contact @luciotato
e-mail: [email protected]
calendly: Calendly - Lucio M. Tato
Thx

I’d like to apologize properly for my harsh reaction above, that wasn’t fair. I guess working in open source for so long, and nowadays often working on more or less frustrating stuff not immediately visible from the outside, has left its scars on me. I certainly should have expressed myself in a more civilized way. Keep up the great work!

The fact that you are passionate and very invested actually reaffirms our belief in AssemblyScript as a project