7 ms·

The main page doesn't do a great job of showing what's interesting about Grain vs. JavaScript. The only hint is this: "No runtime exceptions, ever. Every bit of

The main page doesn't do a great job of showing what's interesting about Grain vs. JavaScript. The only hint is this: "No runtime exceptions, ever. Every bit of Grain you write is thoroughly sifted for type errors, with no need for any type annotations." Maybe show some examples of errors Grain would catch that JavaScript wouldn't, like Elm does: http://elm-lang.org/ http://elm-lang.org/

thangngoc89 8y ago
I think the marketing page is not doing a great job. Grain is a language compiled to WebAssembly. So comparing it with either Javascript or Elm is pointless
- tlrobinson 8y ago
  > So comparing it with either Javascript or Elm is pointless Why? They all target browsers. What else would you compare it to?
  - thangngoc89 8y ago
    Like comparing to Rust compilation to WebAssembly for example?
    - ForHackernews 8y ago
      Does Rust have any DOM integration?
      - ekidd 8y ago
        Yes. For a while, you've been able to embed JavaScript wrappers using stdweb (https://github.com/koute/stdweb https://github.com/koute/stdweb). There are pre-built libraries covering much of the DOM. But you may need to submit PRs if you get heavily into <video> or something else with non-standard APIs. The shiny new toy is wasm-bindgen (https://github.com/rustwasm/wasm-bindgen https://github.com/rustwasm/wasm-bindgen), which will soon allow the use of WebIDL (https://heycam.github.io/webidl/ https://heycam.github.io/webidl/) to wrap the entire browser API, if I understand correctly. In practice, it all seems to work pretty well. But for public-facing sites, you need to watch the number of dependencies you include and keep the *.wasm size down.
        masklinn 8y ago
        There are vdom/components-based libraries based on that as well e.g. Yew seems popular.
- vijaybritto 8y ago
  They've even got the ability to query dom using a light weight lib on the js side. I think this is a more full fledged framework and they should really talk about it. The marketing page is not upto other frameworks imo.
- masklinn 8y ago
  > Grain is a language compiled to WebAssembly. So comparing it with either Javascript or Elm is pointless This ability is a tool and nothing precludes a wasm target for Elm (in fact Evan specifically expressed interest in it: https://github.com/WebAssembly/gc/pull/1#discussion_r111501121 https://github.com/WebAssembly/gc/pull/1#discussion_r1115011...). Either way, comparing Grain to JS or Elm is anything but pointless, at the end of the day it's competing with them.
  - bad_user 8y ago
    If we're speaking of competition and JavaScript, then a much stronger competitor would be PureScript. http://www.purescript.org/ http://www.purescript.org/ PureScript is a Haskell dialect that was built specifically to run on top of JavaScript engines. Specifically, compared with Haskell, it is strictly evaluated (whereas Haskell is non-strict / lazy, well almost). However it eliminates some of Haskell's baggage, but retains Haskell's functional purity. It's all around an awesome programming language for FP that targets JavaScript engines, far surpassing any other attempt.
repsilat 8y ago
> No runtime exceptions, ever. This is something I wonder about JS: there are a lot of places that exceptions happen in (say) Python that just return `NaN` or `undefined` in javascript. Is it intentional? Is it a good idea? Examples: the multiplication operator essentially never throws. Out-of-bounds (or "not found") lookups don't throw. I suspect the logic is "only throw if you have the wrong type for that operation" -- like calling something that isn't a function, or looking up an attribute on something that isn't an object. (Except multiplication for things that aren't numbers is fine, I guess...) I'm writing a dynamically typed language and don't know if it's better to go the JS way or the Python way. Or do something horrible like having multiplication return a `Maybe` type...
- setr 8y ago
  I would argue to throw; there's not much good that comes out of intentionally having an error cascade through the program until reaches a throwable error, or produces incorrect results (this is true for both python and js, but the decision you're making is to allow it more than absolutely necessary for a dynamic lamguage)
- lomnakkus 8y ago
  The JS way is a mistake, intentional or not. Here's a little thought experiment: Your program ends up with an "undefined" in some variable 'x'. How did that happen? In JS it can happen in any number of weird and wonderful ways, e.g. you called a function which did a 'v[i]' or it could have just fallen off the end because someone forgot to check a return path, or... In Python there's much less scope what the problem could be. Since v[i] will just throw an IndexError, you know that the problem couldn't possibly be stray index or similar. That is a much better experience for finding problems in one's code.
  - millstone 8y ago
    But JS programs must execute in uncontrolled environments, e.g. browser engines from the past and future with random extensions installed. A bondage-and-discipline language may help developers find logic bugs, but will make the users' experiences worse.
thefounder 8y ago
I don't think web languages should have comparisons with JS on their homepage now that we have wasm.
- oconnor663 8y ago
  The WASM devs have really been trying to correct the "WASM will replace JS" meme. I don't think any of them believe that it will, or even that it would be a good thing if it did.
  - thefounder 8y ago
    I wonder how many people actually believed that. People want to use their favorite language on both the server and the client/browser. Why is so hard to get this?
tomp 8y ago
I wonder how they handle array out-of-bounds accesses...
- vilu 8y ago
  Maybe by making the API of index based list datatypes return the value inside of a container type. In general it's a helpful strategy when creating total functions.
- dleclere 8y ago
  Looks like they're using an indexed Algebraic Data Type. https://github.com/grain-lang/grain/blob/master/src/grain-stdlib/lists.grlib https://github.com/grain-lang/grain/blob/master/src/grain-st...
  - masklinn 8y ago
    There's no indexing in that.
- masklinn 8y ago
  Likely like Elm, where indexing into an array returns a Maybe. OOB return Nothing, while in-bound returns Just <value>. Or they don't support indexing at all.
mcintyre1994 8y ago
> No runtime exceptions, ever. I'm curious how they handle JSON parsing. For example in Scala/Play you define the class you want to parse to, and if the JSON passed in at runtime doesn't match the shape of that class then you get a runtime exception. Obviously it'd be nice if that didn't happen, but I can't think of any alternative that would make sense.
- pure-awesome 8y ago
  I could be wrong about this, but I think that, like Elm, it's not technically Grain that throws the runtime exception. It's whatever is reading in the JSON. In more detail: It's purely functional, so it cannot handle I/O at all on its own. It needs some sort of harness into which it fits which handles that, and which then calls the pure functions in Elm / Grain. In Elm's case that harness is JavaScript, and it seems to be a similar case for Grain. (Maybe for Grain it's WebAssembly? I don't honestly know enough about Web Dev to say). During I/O (including user input, and sending data over a network), runtime exceptions can still be thrown, but once it's been converted and passed into the functional part, it's in a sense correctly formatted by definition, and the purely functional Elm / Grain parts don't throw runtime exceptions at all.
- diaz 8y ago
  You should look into other more saner json libraries. It's unacceptable to have a runtime error. Nowadays I recommend circe.
- masklinn 8y ago
  > Obviously it'd be nice if that didn't happen, but I can't think of any alternative that would make sense. Returning a sum of success + error, as e.g. Rust's Serde[0] or Elm's Json.Decode[1] do. The developer gets the feedback that the operation has failed at runtime, but they also get the feedback that the operation can fail and they must handle it somehow at compile-time, even ignoring the issue is an explicit decision. [0] https://docs.serde.rs/serde_json/de/fn.from_str.html https://docs.serde.rs/serde_json/de/fn.from_str.html [1] http://package.elm-lang.org/packages/elm-lang/core/latest/Json-Decode#decodeString http://package.elm-lang.org/packages/elm-lang/core/latest/Js...

thangngoc89 8y ago

I think the marketing page is not doing a great job. Grain is a language compiled to WebAssembly. So comparing it with either Javascript or Elm is pointless

tlrobinson 8y ago
> So comparing it with either Javascript or Elm is pointless Why? They all target browsers. What else would you compare it to?
- thangngoc89 8y ago
  Like comparing to Rust compilation to WebAssembly for example?
  - ForHackernews 8y ago
    Does Rust have any DOM integration?
    - ekidd 8y ago
      Yes. For a while, you've been able to embed JavaScript wrappers using stdweb (https://github.com/koute/stdweb https://github.com/koute/stdweb). There are pre-built libraries covering much of the DOM. But you may need to submit PRs if you get heavily into <video> or something else with non-standard APIs. The shiny new toy is wasm-bindgen (https://github.com/rustwasm/wasm-bindgen https://github.com/rustwasm/wasm-bindgen), which will soon allow the use of WebIDL (https://heycam.github.io/webidl/ https://heycam.github.io/webidl/) to wrap the entire browser API, if I understand correctly. In practice, it all seems to work pretty well. But for public-facing sites, you need to watch the number of dependencies you include and keep the *.wasm size down.
      - masklinn 8y ago
        There are vdom/components-based libraries based on that as well e.g. Yew seems popular.
vijaybritto 8y ago
They've even got the ability to query dom using a light weight lib on the js side. I think this is a more full fledged framework and they should really talk about it. The marketing page is not upto other frameworks imo.
masklinn 8y ago
> Grain is a language compiled to WebAssembly. So comparing it with either Javascript or Elm is pointless This ability is a tool and nothing precludes a wasm target for Elm (in fact Evan specifically expressed interest in it: https://github.com/WebAssembly/gc/pull/1#discussion_r111501121 https://github.com/WebAssembly/gc/pull/1#discussion_r1115011...). Either way, comparing Grain to JS or Elm is anything but pointless, at the end of the day it's competing with them.
- bad_user 8y ago
  If we're speaking of competition and JavaScript, then a much stronger competitor would be PureScript. http://www.purescript.org/ http://www.purescript.org/ PureScript is a Haskell dialect that was built specifically to run on top of JavaScript engines. Specifically, compared with Haskell, it is strictly evaluated (whereas Haskell is non-strict / lazy, well almost). However it eliminates some of Haskell's baggage, but retains Haskell's functional purity. It's all around an awesome programming language for FP that targets JavaScript engines, far surpassing any other attempt.

repsilat 8y ago

> No runtime exceptions, ever. This is something I wonder about JS: there are a lot of places that exceptions happen in (say) Python that just return `NaN` or `undefined` in javascript. Is it intentional? Is it a good idea? Examples: the multiplication operator essentially never throws. Out-of-bounds (or "not found") lookups don't throw. I suspect the logic is "only throw if you have the wrong type for that operation" -- like calling something that isn't a function, or looking up an attribute on something that isn't an object. (Except multiplication for things that aren't numbers is fine, I guess...) I'm writing a dynamically typed language and don't know if it's better to go the JS way or the Python way. Or do something horrible like having multiplication return a `Maybe` type...

setr 8y ago
I would argue to throw; there's not much good that comes out of intentionally having an error cascade through the program until reaches a throwable error, or produces incorrect results (this is true for both python and js, but the decision you're making is to allow it more than absolutely necessary for a dynamic lamguage)
lomnakkus 8y ago
The JS way is a mistake, intentional or not. Here's a little thought experiment: Your program ends up with an "undefined" in some variable 'x'. How did that happen? In JS it can happen in any number of weird and wonderful ways, e.g. you called a function which did a 'v[i]' or it could have just fallen off the end because someone forgot to check a return path, or... In Python there's much less scope what the problem could be. Since v[i] will just throw an IndexError, you know that the problem couldn't possibly be stray index or similar. That is a much better experience for finding problems in one's code.
- millstone 8y ago
  But JS programs must execute in uncontrolled environments, e.g. browser engines from the past and future with random extensions installed. A bondage-and-discipline language may help developers find logic bugs, but will make the users' experiences worse.

thefounder 8y ago

I don't think web languages should have comparisons with JS on their homepage now that we have wasm.

oconnor663 8y ago
The WASM devs have really been trying to correct the "WASM will replace JS" meme. I don't think any of them believe that it will, or even that it would be a good thing if it did.
- thefounder 8y ago
  I wonder how many people actually believed that. People want to use their favorite language on both the server and the client/browser. Why is so hard to get this?

tomp 8y ago

I wonder how they handle array out-of-bounds accesses...

vilu 8y ago
Maybe by making the API of index based list datatypes return the value inside of a container type. In general it's a helpful strategy when creating total functions.
dleclere 8y ago
Looks like they're using an indexed Algebraic Data Type. https://github.com/grain-lang/grain/blob/master/src/grain-stdlib/lists.grlib https://github.com/grain-lang/grain/blob/master/src/grain-st...
- masklinn 8y ago
  There's no indexing in that.
masklinn 8y ago
Likely like Elm, where indexing into an array returns a Maybe. OOB return Nothing, while in-bound returns Just <value>. Or they don't support indexing at all.

mcintyre1994 8y ago

> No runtime exceptions, ever. I'm curious how they handle JSON parsing. For example in Scala/Play you define the class you want to parse to, and if the JSON passed in at runtime doesn't match the shape of that class then you get a runtime exception. Obviously it'd be nice if that didn't happen, but I can't think of any alternative that would make sense.

pure-awesome 8y ago
I could be wrong about this, but I think that, like Elm, it's not technically Grain that throws the runtime exception. It's whatever is reading in the JSON. In more detail: It's purely functional, so it cannot handle I/O at all on its own. It needs some sort of harness into which it fits which handles that, and which then calls the pure functions in Elm / Grain. In Elm's case that harness is JavaScript, and it seems to be a similar case for Grain. (Maybe for Grain it's WebAssembly? I don't honestly know enough about Web Dev to say). During I/O (including user input, and sending data over a network), runtime exceptions can still be thrown, but once it's been converted and passed into the functional part, it's in a sense correctly formatted by definition, and the purely functional Elm / Grain parts don't throw runtime exceptions at all.
diaz 8y ago
You should look into other more saner json libraries. It's unacceptable to have a runtime error. Nowadays I recommend circe.
masklinn 8y ago
> Obviously it'd be nice if that didn't happen, but I can't think of any alternative that would make sense. Returning a sum of success + error, as e.g. Rust's Serde[0] or Elm's Json.Decode[1] do. The developer gets the feedback that the operation has failed at runtime, but they also get the feedback that the operation can fail and they must handle it somehow at compile-time, even ignoring the issue is an explicit decision. [0] https://docs.serde.rs/serde_json/de/fn.from_str.html https://docs.serde.rs/serde_json/de/fn.from_str.html [1] http://package.elm-lang.org/packages/elm-lang/core/latest/Json-Decode#decodeString http://package.elm-lang.org/packages/elm-lang/core/latest/Js...