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

121–130 of 156 posts

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

#121

Post by recursive »

galaxyLogic wrote: post #109
repsilat wrote: post #12

Earlier quoted context omitted.

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

I think JavaScript simply got it quite wrong by trying to be way too clever. In theory it is fine to say that dividing by 0 is Infinity but what can you do with Infinity? In practice that causes the output of your program be either Infinity or NaN but the problem is that is usually never what you want. Then you want to know "Why do I get a NaN here?" and you will have to study all of your program and single step its…

> I think JavaScript simply got it quite wrong by trying to be way too clever. In theory it is fine to say that dividing by 0 is Infinity but ...

This wasn't javascript's idea. They're just following the spec. https://en.wikipedia.org/wiki/IEEE_754#Exception_handling

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

#122

Post by sbjs »

The "DOM Interaction" and "DOM Manipulation" sections just show imperative code. So how is this a fundamental improvement over using jQuery? Especially for a language that markets itself as "seriously functional", it feels like a big step backward. I can't see what benefit this actually brings except being easier for OCaml developers to write web apps with. And even then they'd probably have no trouble learning TypeScript which doesn't need a bridge since it's a strict superset of JS.

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

#123

Post by colanderman »

masklinn wrote: post #105
colanderman wrote: post #91

Earlier quoted context omitted.

I would assume case B, which isn't really that unique. Erlang for example follows that pattern (and has no concept of "exception"). After all, I/O errors, parsing errors, etc., aren't exceptional; they very much should be expected. Forcing them to be handled in the normal code path helps create robust systems. (There are of course also true runtime errors -- e.g. out-of-memory -- and precondition errors -- i.e., codi…

> Erlang for example follows that pattern (and has no concept of "exception"). Erlang absolutely has a concept of exceptions. They're even called exceptions: http://erlang.org/doc/reference_manual/errors.html#exception... .

Wow, I used Erlang extensively a few years ago and don't remember exceptions at all. (Exit reasons and process monitors, yes; but I don't think I ever wrote a "catch" expression, or encountered a library that expected me to do so.)

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

#124

Post by lodi »

galaxyLogic wrote: post #107
masklinn wrote: post #104

Earlier quoted context omitted.

> Errors could presumably be provided as return values (similar to Rust's Option or Haskell's Either), though we know from languages like Go that propagating these manually is a chore and an eyesore. Mostly because Go is terrible. > Haskell's type system is extremely powerful, but it cannot catch this at compile time. The problem is not the type system, it's that Haskell's error handling is inconsistent. Elm, despite…

This seems like such an obvious solution it makes me wonder why creators of Haskell did not think of it? Lists are a very basic type used all the time if you don't get that right lot of the value of the great type-system is lost I would think.

They did. The elm-style version is in the standard libraries as:

    listToMaybe :: [a] -> Maybe a
(http://hackage.haskell.org/package/base-4.11.1.0/docs/Data-M...)

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

#125

Post by lomnakkus »

millstone wrote: post #47
lomnakkus wrote: post #33

Earlier quoted context omitted.

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.

Banker vs moon rover. B&D languages panic at the first whiff of deviation between the compile-time and runtime environments. But I loaded cnn.com, and my third-party ad blocker did god-knows-what to dozens of requests, with a bazillion unexpected undefineds, and yet the page still rendered. The web powers through!

This has nothing to do with undefined vs. exceptions, sorry. You can do example the same with a powerful enough sandbox -- e.g. what WebAsm does to avoid hostile code taking over your computer.

It has everything to do with sandboxing (or not). Ads being served by third parties should not be able to influence the JS running in the page.

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

#126

Post by mml »

leshow wrote: post #90
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.

Elm goes even further, insisting that you actually handle the Error types in some way.

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

#127

Post by dragonwriter »

macintux wrote: post #93
colanderman wrote: post #91

Earlier quoted context omitted.

I would assume case B, which isn't really that unique. Erlang for example follows that pattern (and has no concept of "exception"). After all, I/O errors, parsing errors, etc., aren't exceptional; they very much should be expected. Forcing them to be handled in the normal code path helps create robust systems. (There are of course also true runtime errors -- e.g. out-of-memory -- and precondition errors -- i.e., codi…

>> The language uses the type system to propagate such errors. ... > Erlang for example follows that pattern. Erlang is its own beast; if you characterize pattern matching as part of a type system, which I guess it is, then...maybe if you squint? Normal errors are indeed typically reflected in the return value, but if the error pattern doesn't match the code's expectations then a runtime exception is thrown...if you'…

> Normal errors are indeed typically reflected in the return value, but if the error pattern doesn't match the code's expectations then a runtime exception is thrown

With a sufficiently complete static (even inferred) type system, you can catch any possibility of such failures AOT and not run into any error patterns that don't match code expectations at runtime, so while the description isn't literally true of Erlang, Erlang does show a way that it could be true of a language with AOT enforcement of adequate type system.

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

#128

Post by dragonwriter »

atombender wrote: post #99
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…

Errors could presumably be provided as return values (similar to Rust's Option or Haskell's Either), though we know from languages like Go that propagating these manually is a chore and an eyesore. A harder problem is errors that cannot be handled by a simpler type system. For example, consider Haskell's head function, which is defined like this: head :: [a] -> a In other words, it takes a list, and returns the first…

> A harder problem is errors that cannot be handled by a simpler type system. For example, consider Haskell's head function

Haskell's head function is often pointed to as a wart even given Haskell's type system; the signature really ought to be:

  head :: [a] -> Maybe a
With a definition (equivalent to):

  head [] = None
  head x:xs = Some x
It's absolutely not a good example of a source of errors that can't be dealt with in a type system like Haskell's.

> In order to express constraints such as "list must not be empty" or "number must be higher than 1" or "file must be open, the type system needs to understand the semantics of the values expressed by a type system.

Sure, but you don't have to express those as type constraints to avoid runtime errors when they occur; if you can express the distinction in normal code you can use distinctions of return type.

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

#129

Post by cmmartin »

pmontra wrote: post #15
cmmartin wrote: post #9

Earlier quoted context omitted.

Grain is quite different. Grain is more functional (no classes or context, tuples). Dart compiles to Javascript. Grain compiles to web assembly. Dart requires you to define types. Grain provides type safety and zero runtime errors without ever defining types manually.

The documentation about types says to look at the Readme of the compiler, which is very short and doesn't tell anything about types. Same thing for many other entries in the side menu. The examples don't have any type declaration. So, type inference and no reuse of the same variable with a different type, even when forcing mutation? Unfortunately the documentation is still too skinny. A note to language designers: I…

Well if you are worried about those 2 characters, you should be stoked about Grain, because it gives you type safety without ever defining types. Think how many characters you will save in an application by never defining a type and at no cost.

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

#130

Post by [deleted] »

pmontra wrote: post #94
andyonthewings wrote: post #23

Earlier quoted context omitted.

( ) are only optional if { } are mandatory, which is not true for some languages. e.g. in Haxe, one can write static function isEven(n) return if (n i.e. An if expression consists of other expressions that may or may not be a block expression ({ }).

There is a great deal of variability in languages about that. Python ends if lines with a : which might help the parser, but maybe not because it was a late addition to help readability. For me it adds work when moving code around because I have to add or remove the : Ruby does totally without any terminator in that context (in other contexts it has its own {} or do...end). The parser keeps processing successive line…

[deleted]
Post reply on HN