7 ms·

Gren 0.4: New Foundations

69 points by Skinney 2y ago

SillyUsername 2y ago
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?
- Skinney 2y ago
  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
  - anentropic 2y ago
    Why not ReScript?
    - Skinney 2y ago
      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.
  - zellyn 2y ago
    You may be interested in roc-lang.org, which does some of those.
    - Skinney 2y ago
      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 :)
      - tasuki 2y ago
        Why would I choose Gren over Roc? (Or vice versa if you like) Thank you for your efforts by the way!
        Skinney 2y ago
        Gren works equally well for backend and frontend apps, Roc is only backend I believe. Gren targets JS and Roc targets native.
        tasuki 2y ago
        Thank you!
anonzzzies 2y ago
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?).
- Skinney 2y ago
  Gren will probably resemble OCaml more and more in this regard. Today, you use + for numbers, and ++ to concatenate strings and list.
cies 2y ago
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 https://wiki.haskell.org/The_JavaScript_Problem#The_problem
- otabdeveloper4 2y ago
  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!
  - Latty 2y ago
    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/json/latest/ https://package.elm-lang.org/packages/elm/http/latest/Http https://package.elm-lang.org/packages/elm/http/latest/Http
    - otabdeveloper4 2y ago
      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/1c5f2cf34939336ecb79b97bb89d9da6 https://gist.github.com/evancz/1c5f2cf34939336ecb79b97bb89d9...
      - boxed 2y ago
        Overhead? You mean in CPU time or development time?
        otabdeveloper4 2y ago
        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.
fermigier 2y ago
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-differences-between-gren-and-elm 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.
- brabel 2y ago
  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?
  - Skinney 2y ago
    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.
  - mjaniczek 2y ago
    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.
    - brabel 2y ago
      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??
      - Latty 2y ago
        IIRC Lamdera is doing server-side Elm. https://lamdera.com/ https://lamdera.com/
zellyn 2y ago
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.
- tasuki 2y ago
  What are the differences and similarities between Gren and Roc?
  - boxed 2y ago
    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-programmers.md https://github.com/roc-lang/roc/blob/main/roc-for-elm-progra... which doesn't answer this which is the first question imo.
    - zellyn 2y ago
      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)
      - boxed 2y ago
        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.
iamdamian 2y ago
Any plans for typeclasses?
- Skinney 2y ago
  No. Gren will instead pursue parametric modules (OCaml functors).
fire_lake 2y ago
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!)
- Skinney 2y ago
  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.
  - fire_lake 2y ago
    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.
    - Skinney 2y ago
      > 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.
Karupan 2y ago
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.
- Skinney 2y ago
  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 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.
  - Karupan 2y ago
    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.
deleted 2y ago
[deleted]

69 points by Skinney 2y ago

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?

Skinney 2y ago
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
- anentropic 2y ago
  Why not ReScript?
  - Skinney 2y ago
    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.
- zellyn 2y ago
  You may be interested in roc-lang.org, which does some of those.
  - Skinney 2y ago
    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 :)
    - tasuki 2y ago
      Why would I choose Gren over Roc? (Or vice versa if you like) Thank you for your efforts by the way!
      - Skinney 2y ago
        Gren works equally well for backend and frontend apps, Roc is only backend I believe. Gren targets JS and Roc targets native.
        tasuki 2y ago
        Thank you!

anonzzzies 2y ago

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?).

Skinney 2y ago
Gren will probably resemble OCaml more and more in this regard. Today, you use + for numbers, and ++ to concatenate strings and list.

cies 2y ago

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 https://wiki.haskell.org/The_JavaScript_Problem#The_problem

otabdeveloper4 2y ago
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!
- Latty 2y ago
  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/json/latest/ https://package.elm-lang.org/packages/elm/http/latest/Http https://package.elm-lang.org/packages/elm/http/latest/Http
  - otabdeveloper4 2y ago
    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/1c5f2cf34939336ecb79b97bb89d9da6 https://gist.github.com/evancz/1c5f2cf34939336ecb79b97bb89d9...
    - boxed 2y ago
      Overhead? You mean in CPU time or development time?
      - otabdeveloper4 2y ago
        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.

fermigier 2y ago

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-differences-between-gren-and-elm 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.

brabel 2y ago
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?
- Skinney 2y ago
  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.
- mjaniczek 2y ago
  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.
  - brabel 2y ago
    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??
    - Latty 2y ago
      IIRC Lamdera is doing server-side Elm. https://lamdera.com/ https://lamdera.com/

zellyn 2y ago

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.

tasuki 2y ago
What are the differences and similarities between Gren and Roc?
- boxed 2y ago
  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-programmers.md https://github.com/roc-lang/roc/blob/main/roc-for-elm-progra... which doesn't answer this which is the first question imo.
  - zellyn 2y ago
    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)
    - boxed 2y ago
      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.

iamdamian 2y ago

Any plans for typeclasses?

Skinney 2y ago
No. Gren will instead pursue parametric modules (OCaml functors).

fire_lake 2y ago

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!)

Skinney 2y ago
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.
- fire_lake 2y ago
  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.
  - Skinney 2y ago
    > 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.

Karupan 2y ago

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.

Skinney 2y ago
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 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.
- Karupan 2y ago
  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.

deleted 2y ago

[deleted]