Live data from Hacker News

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

grain-lang.org

111–120 of 156 posts

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

#111

Earlier quoted context omitted.

Dart is amazing

Yes, Dart is amazingly broken for a modern language. This compiles: List animals = [Dog()]; List cats = animals; What is a static type system worth if it doesn't catch type errors at compile time?

Dart 2 has a sound type system and catches this at compile time.

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

#112
post #92

Earlier quoted context omitted.

> it's 2018 > type annotations https://en.wikipedia.org/wiki/Type_inference

Type annotations can be helpful in writing maximally polymorphic code and in self documentation, independent of type inference. When I write Haskell, I still annotate my code.

Also, throwing out all type annotations makes code pretty hard to read, especially outside your IDE like in a Github repo.

Taken to an extreme, it feels like reading a dynamically-typed language where you have to keep the various variable types in your head when debugging.

There's a middle ground.

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

#113
post #48

Earlier quoted context omitted.

Moreover, they don't really show anything to make their point — I can't see any type annotations on the frontpage.

> it's 2018 > type annotations https://en.wikipedia.org/wiki/Type_inference

Pretty lazy comment.

There's a reason you still at least annotate the top level in Haskell, Elm, and friends even though the compiler could've inferred it. It's because humans have to read it.

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

#114

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…

Grain dev here! Fixed that on the site. That line was just supposed to be about runtime type errors, not all errors.

Grain is definitely still really in its alpha form. There's lots we want to do with it that we're still getting around to! We weren't quite expecting much of any traffic to the site, but that's really my fault for having the site be public before we were at least a bit further along. :)

Even still, it's been awesome to get a lot of early feedback! We'll get a roadmap together so it's easier for people to see where we're trying to take the language.

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

#115
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"?

Probably because people already have their pick of those languages on the server but not on the browser client where it's even more important to get things right from a UX standpoint.

Static-typing, immutable datastructures, FP... these are things that even the Javascript ecosystem has been moving towards with React, Typescript, Redux, and more.

If you're making a language for the browser, you can offer a lot of value by rolling these into a single tool. For example, it may be much simpler for you to use Elm than to approximate Elm with your own menagerie of JS tools.

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

#116
post #85
post #76

Earlier quoted context omitted.

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?

Well, Grain is as well so is that really an issue?

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

#117
If it's not too late to change, might I suggest doing away with the 'let rec ... and ...' syntax? The way to group mutually recursive bindings can be determined by finding the strongly connected components of the graph of the references between functions, so users don't need to manually specify it.

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

#118
IMO modern web language should have some notion of events as in my Sciter ( https://sciter.com/event-handling/ ) for example:

    event click $(table > thead > tr > th) {
      // click on table header cell
      // 'this' is that th element
    }

    class Widget : Element 
    {
       function attached() {...}

       event click $(span.up) { this.increment(); }
       event click $(span.down) { this.decrement(); }

       event mousedown { this.state.focus = true; } 
       ...
    }

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

#119

IMO modern web language should have some notion of events as in my Sciter ( https://sciter.com/event-handling/ ) for example: event click $(table > thead > tr > th) { // click on table header cell // 'this' is that th element } class Widget : Element { function attached() {...} event click $(span.up) { this.increment(); } event click $(span.down) { this.decrement(); } event mousedown { this.state.focus = true; } ...…

YES. Every time I see a new language come out without first class event support it is obvious the creator never wrote a lick of front end code in their life.

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

#120

If it's not too late to change, might I suggest doing away with the 'let rec ... and ...' syntax? The way to group mutually recursive bindings can be determined by finding the strongly connected components of the graph of the references between functions, so users don't need to manually specify it.

But then how do you shadow previous bindings?

    let f x = if (x == 0) then 0 else (f x)
Post reply on HN