Did they get rid of the whitelist of projects allowed to use native code (https://news.ycombinator.com/item?id=22821447, https://news.ycombinator.com/item?id=17842400, https://news.ycombinator.com/item?id=16510267)?
- There are no changes since HEAD
- The commit is signed by Robin himself
...and for those interested in the code that does this
https://github.com/gren-lang/compiler/blob/main/builder/src/...
Seems more like a check to make sure the version of the JS is compatible with the version of gren than anything else.
[1] https://github.com/gren-lang/compiler/blob/e665e521367eeedec...
Edit: EdwardDiego's answer clarified this for me
And found a great bug where it broke their own code. [1]
[0]: https://github.com/gren-lang/compiler/blob/main/docs/kernel_...
In the past, while using Elm, if you wanted to support some browser API that Elm didn't support yet you would have to fallback to kernel code. What Elm wanted: a core package that provided this low-level kernel package that provided typesafety at the Elm level. But as we know, this was a pipe dream because you could never contribute to Elm unless it was from the Elm dictator itself, or from his inner circle of cool people.
It seems like Gren is already ahead of this. Gren has community members actively working on the Websocket API to provide a typesafe core package with Kernel bindings.
The question is: will Gren keep being open to contributors that can provide kernel code.
I know a lot of people got burned by this when Elm added this enforcement, and that seeing it here in Gren can cause a lot of eyerolls.
However.
The greatest feature of the language is the absence of mutation and user-defined exceptions, and managed side-effects. Making the kernel code api accessible to everyone would introduce those things to the language, and my memory from the pre 0.19 days of Elm tells me that this made for a worse experience overall.
One of the problems with this limitation is the lack of bindings to core web api’s. We’re actively working on adding more APIs here. LocalStorage was contributed by an external contributor. Contributors are also working on a HttpServer and a WebSocket API now.
And that’s another «change» worth noting when comparing with Elm. We have scheduled releases (June and December) and are more open to contributions.
I will have to revisit kernel code at some point in the future, probably when looking into WASM (which will break all uses of kernel code), but I have other, more important, features to add first.
As in, I do get the reasoning, but there are valid situations where one might need to do this for their own reasons. So maybe there’s some way to make it clear that you shouldn’t be doing this, yet still narrowly allow it. A non-default CLI flag, a scary compilation warning, maybe needs to use some special keyword to use code like that. Like how you need to use ‘unsafe’ in Rust to interact with C code directly.
Otherwise, thank you for working on this! An Elm inspired language that’s open to community development is something the world needed :-D
It will be looked at pre 1.0.
My memory tells me that 0.19 literally killed the language.
The main problem with ports is that (1) it's an async API, which can be awkward for certain operations and (2) you cannot define a package that contains ports.