Replies: 2 comments 1 reply
-
Hey @sandstrom, thanks for your questions :)
Generally, the 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
There sure are! There's a PR currently open for it (#1133) and it'll be included in the
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:
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. |
Beta Was this translation helpful? Give feedback.
-
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 I think there's already some issues for a few of the things you mentioned :) |
Beta Was this translation helpful? Give feedback.
-
Hello Grain Team! 👋🏻
Looking at Grain and comparing it a bit to AssemblyScript.
Grain looks awesome, but I have a few questions:
Numbers
In grain there is
Number
,Int32
,Int64
,Float32
,Float64
andBigInt
. 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:
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.
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
Longer-horizon roadmap
see itself?
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
import ImmutableArray from "immutablearray"
to beimport ImmutableArray from "immutable_array"
(or"immutable-array"
), basically a separator because the class is composed of two words.Marshal
is a grab bag of utility methods, andArray
looks like a proper instance. Maybe they should be grouped differently somehow.Random
in the stdlib. Somewhat confusing?Beta Was this translation helpful? Give feedback.
All reactions