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.
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?
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?
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:
@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.
You are welcome! 
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.
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?
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.
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.
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:
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
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