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.
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?).
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.
Thanks for the response! Sounds like most of the major issues I’ve had with Elm are being addressed in some way. Will follow your progress and contribute.
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.
