[bluejekyll]

Everything you listed out is also work going on in Rust as well specifically for targeting WASM, I’m more familiar with Rust, but there are many efforts in other languages too (C, C++, AssemblyScript, etc).

The question in my mind is do we need a language specialized for this? For example, a lot of the design choices of the language, like OCAML inspiration, good FFI are already part of other languages.

While to me that means it will probably be a niche language, the fact that it’s specifically targeting only WASM for now, will probably mean it will be a great language for experimentation that other languages can learn from.

[azakai]

> The question in my mind is do we need a language specialized for this?

Based on my experience writing wasm toolchains, I think specialized languages can have big benefits.

Existing languages always have downsides on the web and in wasm. The downsides are worth it when porting existing code, and often for other reasons, but a new toolchain can avoid them.

A specialized language can design its library for wasm, avoiding unnecessary code, like e.g. string formatting and other libc things in C/C++/Rust (unless you are very careful). Almost no language was designed for emitting small binaries like wasm wants - wasm toolchains for them work hard on this, but there is always some friction.

A specialized language can have async APIs like the web requires, avoiding workarounds there. And it can more easily benefit from new wasm features in some cases, like GC: there is work for that in LLVM, which will give some support for C/C++/Rust, but it will be limited - while I'd expect Grain and AssemblyScript etc. to much more easily and greatly benefit.

Of course specialized languages have downsides too, like limited or less efficient non-wasm ports. There is room for both!

[asiachick]

I'm just going to guess that a language that is WebAssembly only, *if popular*, would eventually have 1000s of libraries that "just work" vs something like Rust where 99% of the code was never designed to run in a WebAssemebly environment and so probably references things that aren't available in that environment (files, networking, windowing systems, stdin/stdout, etc...)

I didn't look at Grain. I'm just thinking out loud what the benefits of a WebAssembly first language could be. It's not so much the language itself though.

[bayesian_horse]

I don't expect Grain to evolve a huge ecosystem of libraries. A good standard library is certainly possible. The rest can be pulled in via Webassembly and Javascript when necessary.

It will probably make sense to use Grain along with React or Vue.js, for example, just because anything else will just not be worth the trouble.

[bluejekyll]

I’ve been working with Rust and WASM for a little while now. I’ll say that at this point the tools in this area are already very good.

Most libraries that implement algorithms and data structures just work. It starts getting messy when things need access to the file system (or other environmental things) but that’s fairly obvious, and what would that be used for in a web context?

WASM already has WASI which is pretty well supported in Rust today, and works well for any POSIX like needs.

In terms of using with React or Vue, I expect no matter the language, the incorporation of WASM modules will be identical (the tooling is where things will set themselves apart).

[bayesian_horse]

The barrier of entry to Rust is large, and I doubt that Rust's WASM integration will be as tight as Grain's just because Rust does a lot of other things.

I'd expect Grain to be easier to learn, and with less distractions from other platforms.

[bluejekyll]

Grain appears to be based on a lot of similar type theory (based on the article). Maybe it will be easier to learn than Rust, maybe not. Maybe there will be fewer tools available and that in and of itself will make it harder to work with.

The question is, will it be worth it to adopt grain instead of a more mainstream language like Rust or AssemblyScript?