[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