[cmmartin]

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.

[pmontra]

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 can understand the { } but if you use them why do you also need the ( ) around the conditionals here?

  if (n <= 1) {
    n == 0
  } else { 
    isOdd(n - 1)
  }

The parser can find where the condition starts (after the if) and ends (at the {) and we won't have to type two useless characters. It's ergonomics.

[andyonthewings]

( ) 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 <= 1)
            n == 0;
        else
            isOdd(n - 1);

    static function isOdd(n)
        return if (n <= 1)
            n == 1;
        else
            isEven(n - 1);

i.e. An if expression consists of other expressions that may or may not be a block expression ({ }).

[pmontra]

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.

[cmmartin]

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.

[pmontra]

Well, the languages I'm using are Ruby, Python, Elixir, JavaScript so I definitely like not to write types. Still, I don't know how types work in Grain. The documentation doesn't say anything about it or it's very well hidden.

[cmmartin]

Are you asking how they are implemented? You'll have to read the compiler code for that. But the documentation does tell you... "No runtime type errors, ever. Every bit of Grain you write is thoroughly sifted for type errors, with no need for any type annotations." So you never write them, but you get all the benefits as if you did.

[pmontra]

Reading the compiler code... well, I think I'll wait they write the documentation.

But how's that possible in general? Example, JSON parsing of data from a HTTP request. This is pseudo code

   # request.data is
   # {"a":1, "b":2, "c":"a string"}
   data = parse(request.data) 
   total = data["a"] + data["b"] # 3
   total = total + data["c"] # ops!

The last line is either a compiler error (how? forbidding input is not an option) or a runtime error (Grain doesn't have that) or what?

[cmmartin]

I imagine the result here would be the same as in Javascript. This is not an error in Javascript. It would concatenate them and convert to a string. So, you would get the string "3a string". I do see your point though and now agree there should be more documentation covering these cases

[devxpy]

So it's more like elm then?

[cmmartin]

More like elm than Dart, but elm also compiles (transpiles?) to javascript and Grain compiles to web assembly