4 ms·

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 WebA

by tmerr 5y ago

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

pjmlp 5y ago
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 5y ago
  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 5y ago
  > 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 5y ago
    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 5y ago
      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 5y ago
        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'
tgv 5y ago
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 5y ago
  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.
bayesian_horse 5y ago
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 5y ago
  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 5y ago
    > 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!
ModernMech 5y ago
> * {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#concatenate https://reasonml.github.io/docs/en/basic-structures#concaten...
pharmakom 5y ago
You would enjoy F# which compiles to JS, Wasm, .Net and native

by tmerr 5y ago

pjmlp 5y ago

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 5y ago
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 5y ago
> 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 5y ago
  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 5y ago
    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 5y ago
      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'

tgv 5y ago

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 5y ago
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.

bayesian_horse 5y ago

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 5y ago
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 5y ago
  > 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!

ModernMech 5y ago

> * {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#concatenate https://reasonml.github.io/docs/en/basic-structures#concaten...

pharmakom 5y ago

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