Planning for AssemblyScript support and integration for the next 6 months, starting Jan'21

Ecosystem
21

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.

22

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.

4 Likes
23

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.

5 Likes
24

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

25

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”.

3 Likes
26

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.
2 Likes
27

@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:

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.

1 Like
28

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.

1 Like
29

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.
1 Like
30

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.

31

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.

1 Like
32

@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?

2 Likes
33

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!)

4 Likes
34

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.

2 Likes
35

@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.

2 Likes
36

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 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.

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.

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.53
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:

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)

2 Likes
37

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! :slight_smile:

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

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 :slight_smile: .

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! :slight_smile: )

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 :slight_smile:

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! :slight_smile: 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.

4 Likes
38

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.

39

@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.

1 Like
40

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.