[tmerr]

IMO the video and the home page grain-lang.org dive too quickly into features without giving a compelling answer to "Why should I use Grain?".

"Powered by WebAssembly": Other languages can compile to WebAssembly as well as other targets. Why is limiting to only one target considered a good thing? What does it buy you? (if it's unique that it has a GC, or if the GC is performant that may be a good reason. Advertise it!).

The vision of bringing ideas from functional/academic languages into the mainstream is noble. But the language features seem very run of the mill? I don't understand what it's referring to.

Comments on the standard library:

* Reference docs should make more clear the differences between Array and List. I assume Array is a fixed size contiguous array of data with constant time get and set? And List is an immutable linked list. But I had to wander around docs and implementation to reach that conclusion.

* Reference docs should probably mention List syntax in the List docs. Ditto for Arrays. You normally expect to see that at the top of the page, vs as a surprising comment "An alias for normal syntactic array access, i.e. array[n].". It's hard to tell what is a library feature vs primitive to the language.

* {Array,List}.append: In most languages I have used append means to append a single element (or in Go's case it is variadic). I would probably rename this to concat and remove the existing concat function.

* What is the benefit to having a separate Stack type vs adding convenience functions to List?

  let List.push = (value, list) => list.
  let List.pop = (list) => (value, list).

[bayesian_horse]

Consider when you want to use WASM in the first place, when it's not just to pull in legacy code (like from C). You'd want to use it for performance-sensitive portions of code. Then it does make sense to have a well thought out language that doesn't have the baggage from other platforms but integrates well with WASM. Similar to "AssemblyScript", but with less baggage from Javascript.

The other advantage of WASM is that it makes Javascript and its runtime get out of the way, enabling Grain to develop its own runtime and standard library. Then you could write a web application (or increasingly other things, too) in Grain, leveraging the language features. The appeal there would be less about performance and more about a more pleasant experience than you'd get with Javascript or Typescript.

That's what I understood. I haven't even tried Grain yet.

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

[pjmlp]

It is just a binary with first class support without needed to install the world like Emscripten does.

I still don't get why so many take the path of installing npm libraries, Python scripts, Java based closure compiler, LLVM based binaren, instead of just generating a wasm file and JS bindings.

Yes I know Grain depends on binaren, just making the point about the dependencies.

[skohan]

Yeah I think decluttering the dependency tree is one of the best things we can do in terms of advancing web development. We're finally getting to the point where a sensible web stack might be possible with WASM and WebGPU, but you still mostly need this miles-deep toolchain to build anything for it

[hobofan]

> instead of just generating a wasm file and JS bindings

"Just"? I think you are severely underestimating the difficulty of creating and maintaining an additional compiler backend for a programming language.

[pjmlp]

Not at all, to give as example, Emscripten already depends on node and npm anyway, why use Python for scripting instead of JavaScript?

Or Java for minification instead to npm based tooling for the same purpose?

[azakai]

Emscripten used to use Java for Closure Compiler minification, but no longer does since there are (AOT compiled Java) binaries available for it, for all major platforms. It fetches them using npm. So that part of your post is a little out of date.

(As to why use Java at all, Closure is written in it, and its advanced optimizations make a huge difference!)

The use of both node and python in Emscripten is slightly redundant. When Emscripten started, node could not yet replace python for what we do with it. Today, if someone wants to refactor that code to node we'd definitely be interested in such a PR! But overall such a refactoring has been lower in priority compared to other work (new wasm features, performance, etc.).

[pjmlp]

Well, thanks for duplicating my node, python and java installations.

    D:\wasm\emsdk>emsdk install latest
    Installing SDK 'sdk-releases-upstream-e0c15cd14170f407a9eb27fcbad22931dc67feb7-64bit'..
    Installing tool 'node-14.15.5-64bit'..
    Downloading: D:/wasm/emsdk/zips/node-v14.15.5-win-x64.zip from https://storage.googleapis.com/webassembly/emscripten-releases-builds/deps/node-v14.15.5-win-x64.zip, 30284821 Bytes
    Unpacking 'D:/wasm/emsdk/zips/node-v14.15.5-win-x64.zip' to 'D:/wasm/emsdk/node/14.15.5_64bit'
    Done installing tool 'node-14.15.5-64bit'.
    Installing tool 'python-3.9.2-1-64bit'..
    Downloading: D:/wasm/emsdk/zips/python-3.9.2-1-embed-amd64+pywin32.zip from https://storage.googleapis.com/webassembly/emscripten-releases-builds/deps/python-3.9.2-1-embed-amd64+pywin32.zip, 16982397 Bytes
    Unpacking 'D:/wasm/emsdk/zips/python-3.9.2-1-embed-amd64+pywin32.zip' to 'D:/wasm/emsdk/python/3.9.2-1_64bit'
    Done installing tool 'python-3.9.2-1-64bit'.
    Installing tool 'java-8.152-64bit'..
    Downloading: D:/wasm/emsdk/zips/portable_jre_8_update_152_64bit.zip from https://storage.googleapis.com/webassembly/emscripten-releases-builds/deps/portable_jre_8_update_152_64bit.zip, 69241499 Bytes
    Unpacking 'D:/wasm/emsdk/zips/portable_jre_8_update_152_64bit.zip' to 'D:/wasm/emsdk/java/8.152_64bit'
    Done installing tool 'java-8.152-64bit'.
    Installing tool 'releases-upstream-e0c15cd14170f407a9eb27fcbad22931dc67feb7-64bit'..
    Downloading: D:/wasm/emsdk/zips/e0c15cd14170f407a9eb27fcbad22931dc67feb7-wasm-binaries.zip from https://storage.googleapis.com/webassembly/emscripten-releases-builds/win/e0c15cd14170f407a9eb27fcbad22931dc67feb7/wasm-binaries.zip, 433852068 Bytes
    Unpacking 'D:/wasm/emsdk/zips/e0c15cd14170f407a9eb27fcbad22931dc67feb7-wasm-binaries.zip' to 'D:/wasm/emsdk/upstream'
    Done installing tool 'releases-upstream-e0c15cd14170f407a9eb27fcbad22931dc67feb7-64bit'.
    Done installing SDK 'sdk-releases-upstream-e0c15cd14170f407a9eb27fcbad22931dc67feb7-64bit'

[ModernMech]

> * {Array,List}.append: In most languages I have used append means to append a single element (or in Go's case it is variadic). I would probably rename this to concat and remove the existing concat function.

Grain is written in Reason, which uses append and concat, so this is probably why Grain does: https://reasonml.github.io/docs/en/basic-structures#concaten...

[tgv]

Indeed. I also don't get from the article or the website what the intention is behind targeting webassembly first, instead of an intermediate that can be compiled to anything.

[bayesian_horse]

Grain already contains language features and a standard library which target the webassembly runtime, and maybe even the browser, explicitly.

It wouldn't make a lot of sense to compile the intermediate (which they probably have, anyway) to anything else.

[pharmakom]

You would enjoy F# which compiles to JS, Wasm, .Net and native