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

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:

1 Like

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

1 Like

You are welcome! :slight_smile:

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

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


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.

2 Likes

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.

1 Like

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

telelgram: Telegram: Contact @luciotato
e-mail: luciotato@narwallets.com
calendly: Calendly - Lucio M. Tato
Thx

1 Like

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!

3 Likes

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

4 Likes