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

91–100 of 156 posts

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

#91

Post by colanderman »

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…

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., coding errors that fall outside the capability of the type system to enforce -- which do not fit this pattern.)

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

#92

Post by leshow »

HindleyMilnerTI wrote: post #51
ealhad wrote: 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

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.

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

#93

Post by macintux »

colanderman wrote: post #91
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…

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're lucky. If the error pattern happens to fit with the pattern match but the code doesn't know about it, eventually some other error will occur.

Anyway, Erlang definitely doesn't fall into the "No runtime exceptions, ever" category, and as such doesn't really fit with the options the OP presented.

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

#94

Post by pmontra »

andyonthewings wrote: post #23
pmontra wrote: post #15

Earlier quoted context omitted.

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…

( ) 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 lines until it understands that what follows can't belong to the conditional. I prefer that approach because it's the language/compiler that has to help me, not the other way around.

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

#95

Post by tomp »

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…

This is actually a really complex problem. Recently in C++, the discussion is happening regarding `nothrow` functions. Can such functions allocate memory (and hence throw "out-of-memory" errors)?

The basic tradeoff is, most program can't (or don't) handle an "out-of-memory" error anyways, so for those, "nothrow" and "nothrow+allocates" is essentially the same. On the other hand, some (few) software is written to handle "out-of-memory" errors, and C++ is one of the few languages that targets such software, so in those programs, the distinction is meaningful.

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

#96

Post by colanderman »

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

I think we read the OP differently. I'm just responding to the bit about errors being returned as an "Either" type. You are right that Erlang does not enforce pattern matching to succeed, though its static analyzer (Dialyzer) can catch many instances when it definitely won't.

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

#98

Post by kazagistar »

zachrose wrote: post #20
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…

Yeah in general it’s good to avoid sometimes returning a value and sometimes undefined. There’s an equivalence you can make between a type and a mathematical set, where you say that the type is the set of all possible values for that type. In both JavaScript and math, multiplication of numbers is an operation that has a special property called closure, which means that the return type is the same as the input types.…

Closure is only good in programming if the answers it gives are always useful. Otherwise, you run into the same non local error problem that plagues nulls: the error still happens, but now it happens at some distant usage site, far away from the cause.

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

#99

Post by atombender »

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 element. But if the list is empty, it throws an exception (technically called an "error" in Haskell):

    > head []
    *** Exception: Prelude.head: empty list
Haskell's type system is extremely powerful, but it cannot catch this at compile time.

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. This can be solved by dependent typing, but that's a complicated concept currently implemented by only a handful of languages (e.g. Idris).

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

#100

Post by tyrel »

jholman wrote: post #53
anonytrary wrote: post #13

I mean, this looks interesting, but why was this posted prematurely? Now I have to remember to look this up again in two months when they actually have a website that isn't 3% done. Basically all of the docs are in the "todo" stage. I always get a bit annoyed when people post their pages way too early.

What makes you think that the HN poster has any affiliation with the project, or vice versa?

Yeah, knowing one of the developers personally, they actually didn't post this. Someone else posted this to Twitter/Reddit/HN.
Post reply on HN