If you're interested in Gren, you might also like Roc — roc-lang.org. It's a definite descendent of Elm too, although not a fork: the compiler is written in Rust, the platforms (a fascinating and powerful concept) in Rust and Zig.
Roc is built by folks who love Elm. They have no desire to replace Elm for web frontend.
IIUC, Roc is what you get if you stir together:
- I like Elm, and wish I could use it in other domains
- I have a bunch of ideas for where Elm could go, but I don't want to mess with Elm
- A really smart, incredibly thoughtful BDFN (benevolent dictator for now)
My worry is that by making it very clear that Gren is a fork of Elm, people will assume that what works in Elm also works in Gren. It won't.
Gren isn't compatible, and will never be compatible, with Elm. There is different syntax, API's and runtime characteristics. And it will continue to diverge more and more.
That Gren is a fork, was mostly to save development time. You can expect that much of the compiler and core packages to be rewritten in a few years.
A big difference seems to be that it can run on NodeJS.
I was a bit confused that the Hello World example shows a web app, but the compiler itself is being rewritten in Gren?! So, the compiler can spit out an executable or JS code, besides HTML?
To clear a possible confusion: Elm runs on NodeJS as well. The reason it's not often done is that the (1st/3rd-party) published packages are heavily skewed towards frontend, because Elm is a language primarily focused on frontend and most of the community uses it for that.
Elm is a frontend language. I know there are efforts to make it runnable on node, but to my knowledge, officially the language is only meant for web applications. The website still seems to confirm that. Can you explain a bit better what you mean??
The historic elm library for unittests does emit js code meant to run on node.
There is also a cottage industry of applications in elm that don’t target the browser like elm-review, and applications running elm code without using its js output, like elm-test-rs. These are made possible by the relative simplicity of elm’s syntax and semantics, which mean getting a workable ast is easy.
It can. If you pass the compiler a output name that has no extension it will produce an executable (js with shebang), and if it has a .js extension it will output a pure js file.
This (Gren), Elm (what Gren is based off), PureScript (more full featured: has Haskell's type classes), Gleam (targets both on BEAM and the browser) -- all really good attempts to fix the JavaScript problem.
It boggles the mind that none of these "solutions" can parse JSON from an API endpoint, even after all these years. Consuming web API's is the whole reason Javascript exists in the first place!
We parse JSON all the time, there are even ways to generate an JSON-parser-in-Elm for you based on an example!
What we do, is leave this up to generated code. We have OpenAPIv3 specs for our APIs and we use the OpenAPIv3-Elm-client-generator to generate the client so we do not deal with JSON parsing etc. ourselves.
What? I've written a bunch of Elm doing JSON parsing and this just isn't true at all. Writing the decoders isn't hard and gives you nice typed and consistent data formats, which is extremely useful.
I don't know what you mean by "defeats the point of using Elm in the first place", what is the point, and how is it defeated?
If anything, since using Elm I trend towards using things like io-ts or zod to replicate it when I'm working with TypeScript because it is so much better to get that consistency and validation.
OCaml isn’t pure. Elm will not support mutations, exceptions or unmanaged side effects. This makes it easier to reason about code, even code that you didn’t write yourself.
My main worry about pure functional languages is that you are at the mercy of the compiler for optimization - for better or for worse. In OCaml or F# I can hand-write things in an imperative way on hot paths. This still doesn’t prevent OCaml from having great optimization passes.
Elm numbers are JavaScript numbers, so divide by zero returns NaN, it doesn't crash.
Although there are other instances that definetly can crash your program, Elm code doesn't allow you to throw or catch exceptions as a language feature.
> My main worry about pure functional languages is that you are at the mercy of the compiler for optimization
It's a scale. There are many ways to optimize outside of using mutation, and allowing for imperative code does prevent certain kinds of optimizations. In general though, the trade off with a language like Gren is that you value correctness and readability more than performance. For me, for the sort of projects I work on, I've never hit an unsolvable performance problem with a pure language. Your milage may vary.
1. Yes and no. Improvements are planned, but kernel code as it exists today will probably be removed. I talked more about this here: https://youtu.be/0Lqc3SK6krA
2. Yes. Most of the pieces are implemented already, and we support local dependencies (as in, depend on a package on your local disk). We "just" need to figure out how to represent a remote repo in gren.json (easy) and what to do with name collisions (less easy).
3. Yes. Gren-in-Gren is currently underway. Once the parser is re-written, it will be made available as a package. This means it should be easy for anyone to write an LSP, formatter, linter etc. But it wouldn't surprise me if LSP becomes integrated with the compiler.
I like the explanation why it is simple. In reality people won't like this because they like something like '+' to mean more things. Look at how rapidly people get 'upset' with OCaml because '+' and '+.' etc. Seems Gren does not go that far, but does not allow + for strings or any conversion (although + is for floats?).
This looks like a fun language to learn if you have the time, I prefer the syntax Vs Go.
I have a concern that as with most new new languages adoption and commercial support affects the uptake, a chicken and egg scenario.
Early days at 0.4 but what are the future plans?
Thank you! I'm already aware of Richard's project and I wish it all the best. You'll find that Gren and Roc differs in certain aspects, though, at least today. It'll be interesting to see how the languages evolve :)
The big thing with Gren is that it's easy to anticipate what your code will do, even when calling functions you don't know the implementation of. It's hard to do this when function calls can mutate state, throw unchecked exceptions or perform arbitrary and unmanaged side effects.
Gren tries to do without these (mutation, unchecked exceptions, unmanaged side-effects) without requiring too much effort on the developer's part. In return, you can easier reason about the behaviour of your program.
Elm proved, at least to me, that this was good way to write programs. Gren simply tries to take it a step further by including first class support for backend applications and command line tools through NodeJS.
If you're interested in Gren, you might also like Roc — roc-lang.org. It's a definite descendent of Elm too, although not a fork: the compiler is written in Rust, the platforms (a fascinating and powerful concept) in Rust and Zig.
What are the differences and similarities between Gren and Roc?
I don't see how to make Single Page Apps, or really anything client side in Roc. I'm quite frustrated by https://github.com/roc-lang/roc/blob/main/roc-for-elm-progra... which doesn't answer this which is the first question imo.
Roc is built by folks who love Elm. They have no desire to replace Elm for web frontend.
IIUC, Roc is what you get if you stir together:
- I like Elm, and wish I could use it in other domains - I have a bunch of ideas for where Elm could go, but I don't want to mess with Elm - A really smart, incredibly thoughtful BDFN (benevolent dictator for now)
Ok sure. But as someone coming from Elm the first question when looking at Roc will be "how does it work for web frontend?"
If the answer is "use Elm", then I guess that's fine, but that answer needs to be in the FAQ.
I also find it a weird answer honestly. Having two such similar languages for frontend and backend, but without being able to share code seems weird.
I had a hunch reading the home page that Gren and Elm were related. This is confirmed by this page:
https://gren-lang.org/book/appendix/faq/#what-are-the-differ...
IMHO it should be more prominent on the hope page or the elevator pitch.
My worry is that by making it very clear that Gren is a fork of Elm, people will assume that what works in Elm also works in Gren. It won't.
Gren isn't compatible, and will never be compatible, with Elm. There is different syntax, API's and runtime characteristics. And it will continue to diverge more and more.
That Gren is a fork, was mostly to save development time. You can expect that much of the compiler and core packages to be rewritten in a few years.
A big difference seems to be that it can run on NodeJS. I was a bit confused that the Hello World example shows a web app, but the compiler itself is being rewritten in Gren?! So, the compiler can spit out an executable or JS code, besides HTML?
To clear a possible confusion: Elm runs on NodeJS as well. The reason it's not often done is that the (1st/3rd-party) published packages are heavily skewed towards frontend, because Elm is a language primarily focused on frontend and most of the community uses it for that.
Elm is a frontend language. I know there are efforts to make it runnable on node, but to my knowledge, officially the language is only meant for web applications. The website still seems to confirm that. Can you explain a bit better what you mean??
The historic elm library for unittests does emit js code meant to run on node.
There is also a cottage industry of applications in elm that don’t target the browser like elm-review, and applications running elm code without using its js output, like elm-test-rs. These are made possible by the relative simplicity of elm’s syntax and semantics, which mean getting a workable ast is easy.
IIRC Lamdera is doing server-side Elm. https://lamdera.com/
It can. If you pass the compiler a output name that has no extension it will produce an executable (js with shebang), and if it has a .js extension it will output a pure js file.
Somewhat off topic but what is the status of Elm these days? Seems like it's been effectively abandoned.
Yea, it's abandoned, or development is slow enough to be the same thing.
I use Elm in production and am quite happy with it. Abandoned or not doesn't seem like an issue in practice.
Complete.
(I sure don't miss the constant breakage)
It has been complete for years, despite targetting an api that never ceased to evolve. Its bugs are not fixed, including todos in core libraries.
Practically, it’s abandoned.
This (Gren), Elm (what Gren is based off), PureScript (more full featured: has Haskell's type classes), Gleam (targets both on BEAM and the browser) -- all really good attempts to fix the JavaScript problem.
https://wiki.haskell.org/The_JavaScript_Problem#The_problem
don't forget rescript and melange, which are attempts to integrate ocaml into the javascript ecosystem
It boggles the mind that none of these "solutions" can parse JSON from an API endpoint, even after all these years. Consuming web API's is the whole reason Javascript exists in the first place!
Am I misunderstanding you, or are you extremely misinformed? Elm can definitely consume JSON APIs.
https://package.elm-lang.org/packages/elm/json/latest/ https://package.elm-lang.org/packages/elm/http/latest/Http
Technically it can. In practice it is a massive overhead and defeats the purpose of using Elm in the first place.
Their solution is, uhm, to wait until JSON disappears and the problem fixes itself, I kid you not: https://gist.github.com/evancz/1c5f2cf34939336ecb79b97bb89d9...
We parse JSON all the time, there are even ways to generate an JSON-parser-in-Elm for you based on an example!
What we do, is leave this up to generated code. We have OpenAPIv3 specs for our APIs and we use the OpenAPIv3-Elm-client-generator to generate the client so we do not deal with JSON parsing etc. ourselves.
Overhead? You mean in CPU time or development time?
Development time.
"Parse API-produced JSON as a contract" is exactly the kind of programming problem pure functional languages were supposed to solve.
And we're building horrific and error-prone rube-goldberg machines to bolt onto our functional programming languages instead.
> And we're building horrific and error-prone rube-goldberg machines to bolt onto our functional programming languages instead.
You literally make no sense to me. Are you sure we are talking about the same thing?
I mean sure: writing JSON parsers takes time, but once written they are awesome.
> writing JSON parsers takes time
The promise of pure functional programming was to never write a 'JSON parser' by hand ever again. (Among other things.)
The paradigm failed because people in charge of Haskell and Elm and other similar languages failed at their job.
What? I've written a bunch of Elm doing JSON parsing and this just isn't true at all. Writing the decoders isn't hard and gives you nice typed and consistent data formats, which is extremely useful.
I don't know what you mean by "defeats the point of using Elm in the first place", what is the point, and how is it defeated?
If anything, since using Elm I trend towards using things like io-ts or zod to replicate it when I'm working with TypeScript because it is so much better to get that consistency and validation.
How does Green plan to distinguish itself from OCaml given that you can transpile OCaml to JS and run it in Node today?
(I’m a big fan of MLs so this is a genuine question!)
OCaml isn’t pure. Elm will not support mutations, exceptions or unmanaged side effects. This makes it easier to reason about code, even code that you didn’t write yourself.
I think that Elm has divide by zero exceptions?
My main worry about pure functional languages is that you are at the mercy of the compiler for optimization - for better or for worse. In OCaml or F# I can hand-write things in an imperative way on hot paths. This still doesn’t prevent OCaml from having great optimization passes.
> I think that Elm has divide by zero exceptions?
Elm numbers are JavaScript numbers, so divide by zero returns NaN, it doesn't crash.
Although there are other instances that definetly can crash your program, Elm code doesn't allow you to throw or catch exceptions as a language feature.
> My main worry about pure functional languages is that you are at the mercy of the compiler for optimization
It's a scale. There are many ways to optimize outside of using mutation, and allowing for imperative code does prevent certain kinds of optimizations. In general though, the trade off with a language like Gren is that you value correctness and readability more than performance. For me, for the sort of projects I work on, I've never hit an unsolvable performance problem with a pure language. Your milage may vary.
I’ve asked this somewhere before, but didn’t get an answer. Are there plans for Gren to:
1. Improve FFI (aka Elm Kernel for everyone) 2. Support Self hosted packages 3. Implement LSP for better IDE integration?
Im cautiously optimistic about Gren, and hopefully some of these concerns can be addressed.
1. Yes and no. Improvements are planned, but kernel code as it exists today will probably be removed. I talked more about this here: https://youtu.be/0Lqc3SK6krA
2. Yes. Most of the pieces are implemented already, and we support local dependencies (as in, depend on a package on your local disk). We "just" need to figure out how to represent a remote repo in gren.json (easy) and what to do with name collisions (less easy).
3. Yes. Gren-in-Gren is currently underway. Once the parser is re-written, it will be made available as a package. This means it should be easy for anyone to write an LSP, formatter, linter etc. But it wouldn't surprise me if LSP becomes integrated with the compiler.
I like the explanation why it is simple. In reality people won't like this because they like something like '+' to mean more things. Look at how rapidly people get 'upset' with OCaml because '+' and '+.' etc. Seems Gren does not go that far, but does not allow + for strings or any conversion (although + is for floats?).
Gren will probably resemble OCaml more and more in this regard.
Today, you use + for numbers, and ++ to concatenate strings and list.
This looks like a fun language to learn if you have the time, I prefer the syntax Vs Go. I have a concern that as with most new new languages adoption and commercial support affects the uptake, a chicken and egg scenario. Early days at 0.4 but what are the future plans?
On the top of my head, the major features to come are:
* Compile to WASM
* Parametric modules (OCaml functors)
* Structural (as opposed to nominal) unions
* Improvements to the Ports (FFI) mechanism while still retaining purity
* Actors(?)
* Support more builtin Browser and NodeJS APIs out of the box
You may be interested in roc-lang.org, which does some of those.
Thank you! I'm already aware of Richard's project and I wish it all the best. You'll find that Gren and Roc differs in certain aspects, though, at least today. It'll be interesting to see how the languages evolve :)
Why would I choose Gren over Roc? (Or vice versa if you like)
Thank you for your efforts by the way!
Gren works equally well for backend and frontend apps, Roc is only backend I believe.
Gren targets JS and Roc targets native.
Thank you!
Why not ReScript?
ReScript isn't pure.
The big thing with Gren is that it's easy to anticipate what your code will do, even when calling functions you don't know the implementation of. It's hard to do this when function calls can mutate state, throw unchecked exceptions or perform arbitrary and unmanaged side effects.
Gren tries to do without these (mutation, unchecked exceptions, unmanaged side-effects) without requiring too much effort on the developer's part. In return, you can easier reason about the behaviour of your program.
Elm proved, at least to me, that this was good way to write programs. Gren simply tries to take it a step further by including first class support for backend applications and command line tools through NodeJS.
Any plans for typeclasses?
No. Gren will instead pursue parametric modules (OCaml functors).