Live data from Hacker News

Grain: A strongly-typed functional programming language for the modern web

grain-lang.org

31–40 of 156 posts

Re: Grain: A strongly-typed functional programming language for the modern web

#31

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/

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

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.

Re: Grain: A strongly-typed functional programming language for the modern web

#32

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/

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

Re: Grain: A strongly-typed functional programming language for the modern web

#33

Earlier quoted context omitted.

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 c…

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.

How is "there was a JavaScript error on this page" informational icon any worse than an order total of "undefined" or that the page just doesn't seem to be reacting to clicks? I'd argue that the former is much better UX -- at least the user isn't confused whether it's them that's doing something wrong or it's the page that just shoddily implemented.

Re: Grain: A strongly-typed functional programming language for the modern web

#34

Earlier quoted context omitted.

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

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.

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?

Re: Grain: A strongly-typed functional programming language for the modern web

#35
post #25

Why not just compile OCaml to wasm? Why another language?

Poking around in the sources, it looks like this is the OCaml compiler, with the frontend apparently tweaked to accept the new syntax. But this is not mentioned anywhere that I can see. The "Copyright copyright 2017-2018 Philip Blair and Oscar Spencer." line in the README is highly misleading in this context, since most of the actual source files are marked with OCaml's copyright header.

Many files are taken from the OCaml compiler and then adapted, but changes seems a bit deeper than just a different syntax. It would indeed seem fair for the authors to at least make it clear in the toplevel README that the front-end (parsetree representation and type-checking) is indeed / started as a fork of the OCaml code base.

Considering ongoing efforts to create a WebAssembly backend for OCaml (and thus Reason), I wonder what would be the selling point of Grain.

Re: Grain: A strongly-typed functional programming language for the modern web

#37
post #36

Doesn't encourage immutability because variables are not readonly by default. I would advice the language designers to require the "mutable" keyword for variables than can be re-assigned. (Similar to F# approach.)

I think you're mistaken. It seems to me that you need to create an explicit "box" (a reference) to make things mutable.

Re: Grain: A strongly-typed functional programming language for the modern web

#38
post #36

Doesn't encourage immutability because variables are not readonly by default. I would advice the language designers to require the "mutable" keyword for variables than can be re-assigned. (Similar to F# approach.)

ML approach.

Re: Grain: A strongly-typed functional programming language for the modern web

#39
post #32

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/

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

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.

Re: Grain: A strongly-typed functional programming language for the modern web

#40
I have a distrust for languages that advertise themselves as "strongly-typed" or "bringing sanity to the front-end" - the former doesn't have a single clear definition and the latter - while not the case here - is questionable in it's own right.
Post reply on HN