Types and overall grain direction

[sandstrom]

Hello Grain Team! 👋🏻

Looking at Grain and comparing it a bit to AssemblyScript.

Grain looks awesome, but I have a few questions:

1. Numbers

   In grain there is Number, Int32, Int64, Float32, Float64 and BigInt. I'm trying to understand why there are so many, or if some of them are more "internal" in nature?

   For example, the basic example doesn't seem to do any typing:

   let firstNumber = 3, secondNumber = 4
   let thirdNumber = firstNumber + secondNumber
   

   If some of them are only internal, maybe you should mark them as such in the API docs, and mention that most implementations won't use them directly.

   My impression is that Grain tries to avoid doing too much complicated typing, and
   have the compiler "figure things out". I think that's a great idea, makes it much more
   accessible. But the large number of number classes seems to go against this.

2. JSON parsing

   Are there plans to include JSON parsing in the Grain std lib?

   While we're waiting for bindgen and the component model, passing in JSON data via memory and
   decoding/encoding is how we get data in/out of a WASM module. So for us, access to a JSON
   lib is needed (haven't tried the library below though, it may work for us).

   I noticed this library:
   https://github.com/cician/grain-json

3. Longer-horizon roadmap

   • Is there a roadmap for the longer-term (e.g. next 1-2 years) for Grain?
   • Or maybe a goals document?
     • So basically, where in the large universe of computer languages does Grain
       see itself?
     • What are the benefits of using Grain over a growing group of languages
       that compile to WASM?

   I like Grain, but it would be helpful for people evaluating it to understand what
   it aims to be, and what it doesn't aim to be.

   Fast? Developer friendly? Functional? Imperative? Small footprint? Mostly type-free syntax despite typing?

   Some of these are tradeoffs, you can't get all of them.

Feedback

• I had expected import ImmutableArray from "immutablearray" to be import ImmutableArray from "immutable_array" (or "immutable-array"), basically a separator because the class is composed of two words.
• "An immutable array implementation, providing fast arbitrary lookups and modifications." fast modifications? but it's immutable? Maybe this can be reworded?
• The standard library has no differentiation between utils and classes. For example, Marshal is a grab bag of utility methods, and Array looks like a proper instance. Maybe they should be grouped differently somehow.
• There are two Random in the stdlib. Somewhat confusing?
• Graindoc looks awesome! Good idea (https://grain-lang.org/docs/tooling/graindoc).
• Nice with a VS Code plugin (vscode-grain)!

[ospencer]

Hey @sandstrom, thanks for your questions :)

In grain there is Number, Int32, Int64, Float32, Float64 and BigInt. I'm trying to understand why there are so many, or if some of them are more "internal" in nature?

Generally, the Number type exists to be your go-to Number type—it supports ints, floats, and rational numbers. This works for most people in 95% of cases, but sometimes you need the added type safety of guaranteeing that a number is definitely an integer, so you might reach for one of the other types. Other than that, they are mostly there to facilitate lower-level programming (think binding to WebAssembly host functions and the like, the four fixed-size number types directly mimic the four WebAssembly native types).

As a bit of a sneak preview, we're currently investigating some major changes to the type system to provide much better ergonomics around the Number type, namely allowing it to be as flexible as it currently is while still providing a good amount of type safety, i.e. knowing that 1 + 5 will produce an integer and restrict functions to work on more fine-grained number types. Lots to work out there, so that change won't be coming until sometime closer to the end of the year, but one I'm pretty excited about.

Are there plans to include JSON parsing in the Grain std lib?

There sure are! There's a PR currently open for it (#1133) and it'll be included in the v0.6.x version stream of Grain, the next major release.

Is there a roadmap for the longer-term (e.g. next 1-2 years) for Grain?

We've got a brand new website in the works with much better messaging about what we aim to be and our longer-term plans. Since that's not out yet, I can give you our two high-level goals:

• Continue to improve the language and tooling within the Grain ecosystem (think general ergonomics, more standard libraries, larger features like macros and async, and a package manager)
• Continue to improve the language and tooling within the larger WebAssembly ecosystem (e.g. first-class support for the component model)

Overall, Grain aims to be a developer-focused pragmatic functional language. A language that allows the developer to be as productive as possible with code that's exceptionally easy to maintain. We're shooting for Python/Ruby levels of productivity, but quite a bit easier level of maintenance due to the type system. We do understand that will cause us to take a hit on performance, but it's something we're aware of—having wasm as a compile target helps a ton on this front.

We want people to choose Grain to write their business logic because they just find it to be the easiest way to get going and get working products out the door quickly, but maybe choose to write their cryptography library in something like Rust. It's a long journey ahead, but we're along for the ride.

[sandstrom]

Thanks Oscar, great answers! Very helpful!

Have a good weekend! ☀️

[ospencer]

If there's feedback for specific things you can feel free to open issues or PRs to address them, that'd be the most helpful. There are some fairly big changes coming in v0.6, including a new module system that helps a ton with organization—for example, the immutable array library will be available as Array.Immutable.

I think there's already some issues for a few of the things you mentioned :)