Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

grain-lang.org

Post reply on HN
Print view View original

81–90 of 156 posts

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

#81

Post by masklinn »

repsilat wrote: post #12
tlrobinson wrote: post #5

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/

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

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

Yes and no respectively.

It's intentional in the sense that the original Javascript was not intended to fault (much) because it was for basic scripting, so if one small script blew up it should not bring down the entire page's scripting. This also resulted in Javascript's exceptions facilities being very shitty (exception handling is not very flexible/convenient, and while that may have changed since — not sure — for a long time it was impossible to sub-type the native Error).

However it's not really a good idea for non-trivial software systems, it makes errors much harder to notice, recover from and debug. In fact "modern" JS APIs tend to fault e.g. parsing invalid JSON raises SyntaxError, it doesn't return null or undefined; and promises and async functions will convert exceptions to failures.

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

#82

Post by bad_user »

masklinn wrote: post #56
thangngoc89 wrote: post #6

Earlier quoted context omitted.

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

> 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_r1115011... ). Either way, comparing Grain to JS or Elm is anything but pointless, at the end of the day it's competing with them.

If we're speaking of competition and JavaScript, then a much stronger competitor would be PureScript.

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.

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

#83

Post by bad_user »

masklinn wrote: post #57
mcintyre1994 wrote: post #45

Earlier quoted context omitted.

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

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

In Scala too well grown libraries return errors via sum types, e.g. Either.

In Play this is actually something like JsSuccess/JsError, not an exception, although Play is pragmatic (aka dirty) at times, so it's possible that it has functions throwing exceptions.

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

#84

Post by marijn »

millstone wrote: post #22

What is meant by "zero runtime errors?" An example of a "runtime error" is the head of an empty list; how does Grain handle this?

The DOM example further down the page, which does no result checking on queries that can absolutely fail to find an element, makes me very skeptical of this claim.

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

#85

Post by nine_k »

wffurr wrote: post #76
nine_k wrote: post #75

Since it's pretty ML-flavored, a comparison with Reason [1] would be nice. I see compiling to WASM as the key differentiator now. This likely means that all the mechanics required for an ML-style language, like garbage collection, must be included in a runtime library. [1]: https://reasonml.github.io/

Only until the WebAssembly spec included access to the host GC: >>> there's already a very efficient, solidly tested, constantly improving garbage collector in your browser that uses all the possible dirty low-level tricks known to mankind, which is the GC being used for JavaScript. What if we could give you access to the garbage collector directly? https://blog.benj.me/2018/07/04/mozilla-2018-faster-calls-an...

Isn't it still pretty experimental?

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

#86

Post by bad_user »

rkangel wrote: post #69

Why do all new languages aimed at the browser seem to be "strongly typed, functional". I have no objection whatsoever, but we've seen Elm, Purescript and now this. Or is my perception skewed by the "HN Echo Chamber"?

"Strong typing" as a term has actually been muddied and doesn't mean much nowadays other than "not C", being re-purposed for marketing reasons. Irregardless of the language, you don't want your language to be weakly typed, although in fact you can say that about most dynamically typed languages.

Leaving the marketing efforts aside, what people want to express is "statically typed". A static type system can prove a lot of things about your program. Traditionally you could rely on (good) static type system to prove that your program is memory safe, or that it has as few runtime errors as possible, preferably zero. N.B. don't fall into the trap of saying that a language like C is statically typed. When you can pass void pointers around and cast that to anything, that's in fact not static typing.

Type theory has a lot to do with math logic actually, the two being highly interchangeable. Statically typed compilers can prove various properties about your program, freeing the developer from writing certain classes of tests, plus it makes refactoring easier.

Refactoring, correctness, these are things people have always struggled with in JavaScript, especially due to JavaScript's nature. Quick, can you tell me the answer to "Math.min() " in JavaScript?

You know it's a trick question, given this is JavaScript, don't you ;-)

---

Other than ClojureScript, I don't know of any other dynamic language targeting JavaScript engines and that's interesting. None. And ClojureScript is only interesting because it is a LISP and because it has sane conventions and defaults.

Languages providing superficial syntactic sugar, such as CoffeeScript, have been a really bad idea and I'm glad that we've moved on.

Therefore the innovation that happens tends to happen in statically typed languages, because there's a lot there left to explore and because such languages tend to bring value.

That said I always wonder what new languages bring to the table versus already available alternatives like PureScript, Scala.js, ClojureScript, Elm, etc. And from the TFA I don't understand what those advantages are.

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

#89

Post by rzwitserloot »

Pretty much the first sentence on the page:

> No runtime exceptions, ever. Every bit of Grain you write is thoroughly sifted for type errors, with no need for any type annotations.

That's... weird to me. That seems to posit that ALL runtime exceptions are necessarily type errors. Huh?

What about full disk, DB errors, data verification error, parsing errors, network errors, and tons of other errors that don't appear to be type system related?

[A] This language only doesn't realize this class of errors exist, which, um, seriously? That can't bode well.

[B] The language uses the type system to propagate such errors. `Either` for example. The language is somewhat unique in that it is designed to enforce such code style for ALL possible error conditions.

[C] The language returns null or blank objects on error conditions, such as how (early) javascript returns 'NaN' when trying to parse "hello!" as a number, instead of raising an error condition. That's a style choice I really wouldn't like, but I guess to each their own.

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

#90

Post by leshow »

rzwitserloot wrote: post #89

Pretty much the first sentence on the page: > No runtime exceptions, ever. Every bit of Grain you write is thoroughly sifted for type errors, with no need for any type annotations. That's... weird to me. That seems to posit that ALL runtime exceptions are necessarily type errors. Huh? What about full disk, DB errors, data verification error, parsing errors, network errors, and tons of other errors that don't appear t…

The likely reason is B. Elm is a frontend web language that also has this guarantee, and it uses Either types for situations that can fail. It's not entirely unique in that regard, there are other languages (mostly) without exceptions; Rust, for example.
Post reply on HN