4 ms·

Grain is quite different. Grain is more functional (no classes or context, tuples). Dart compiles to Javascript. Grain compiles to web assembly. Dart requires y

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 8y ago
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 8y ago
  ( ) 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 8y ago
    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.
    - deleted 8y ago
      [deleted]
- cmmartin 8y ago
  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 8y ago
    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 8y ago
      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 8y ago
        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 8y ago
        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 8y ago
So it's more like elm then?
- cmmartin 8y ago
  More like elm than Dart, but elm also compiles (transpiles?) to javascript and Grain compiles to web assembly

pmontra 8y ago

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 8y ago
( ) 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 8y ago
  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.
  - deleted 8y ago
    [deleted]
cmmartin 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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 8y ago
        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 8y ago

So it's more like elm then?

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