Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gren – an Elm fork

gren-lang.org

Post reply on HN
Print view View original

91–100 of 129 posts

Re: Gren – an Elm fork

#91

Post by nrabulinski »

Skinney wrote: post #74

Lead developer here. I think it’s a little misleading that the title of this post is «Gren - an Elm fork». While technically correct, I think there are many who will be dissapointed to find that Gren and Elm are incompatible languages. In addition to some syntax changes and improvements, Gren adds the support of a NodeJS target. It’s still early, so we don’t support all of the builtin APIs yet, but we’ll slowly get t…

Unrelated to Gren, but what happened to Stabel? It seemed like a very cool and interesting project yet when I wanted to read more about it, all the resources were down

Re: Gren – an Elm fork

#92

Post by Skinney »

rapind wrote: post #84
Skinney wrote: post #74

Lead developer here. I think it’s a little misleading that the title of this post is «Gren - an Elm fork». While technically correct, I think there are many who will be dissapointed to find that Gren and Elm are incompatible languages. In addition to some syntax changes and improvements, Gren adds the support of a NodeJS target. It’s still early, so we don’t support all of the builtin APIs yet, but we’ll slowly get t…

As someone who uses and is generally pleased with Elm (a large part of my product's UI is Elm) I could use more detail on what is different and especially why it is different. I did find a news post listing some differences, but it didn't really go into "why". A dedicated page outlining the differences / opinions on the changes would help me determine if this is a language I might use. Having a NodeJS (server) target…

No tuples: I found this to trade some convinience (no need to name anything)for worse refactoring (adding a value to a tuple or reordering the fields breaks everything, doing the same to a record doesn’t).

I also improved pattern matching on records to make them more ergonomic.

No automatic record constructors: same as the above, but in my experience it also confused beginners.

I know of several that actively avoids it in their projects, even enforcing it with a linter rule.

No GLSL: never used it, and don’t know how it works. It also broke when I upgraded the version of the Haskell compiler (Gren’s compiler is written in Haskell). For those reasons, it was removed.

No reactor: never used it

Re: Gren – an Elm fork

#93

Post by brabel »

josephcsible wrote: post #10

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

Those links you provided seem to have nothing to do with "whitelist of projects allowed to use native code". Can you be more specific about what you're referring to?

Re: Gren – an Elm fork

#94

Post by Cupprum »

m8s wrote: post #49
vbezhenar wrote: post #33

Earlier quoted context omitted.

So elm is abandoned or there's more to this story?

There's more to the story in that Elm is a stable, high-quality frontend language that works as well as its creator wants it to for now. There are a lot of happy Elm users over on the Elm Slack, and it's being used in production at various companies. There's also [Elm on the Backend]( https://gotoaarhus.com/2023/sessions/2529/elm-on-the-backend ), a recent talk given by the creator of Elm, about his experiments in us…

I saw the Elm on the Backend presentation. Evan would like ELM to be a full stack language. If it will work properly, you will not have to manage the message passing (JSON, XML). Seems like very interesting topic. Evan looked really psyched about.

Re: Gren – an Elm fork

#95

Post by brabel »

m8s wrote: post #49
vbezhenar wrote: post #33

Earlier quoted context omitted.

So elm is abandoned or there's more to this story?

There's more to the story in that Elm is a stable, high-quality frontend language that works as well as its creator wants it to for now. There are a lot of happy Elm users over on the Elm Slack, and it's being used in production at various companies. There's also [Elm on the Backend]( https://gotoaarhus.com/2023/sessions/2529/elm-on-the-backend ), a recent talk given by the creator of Elm, about his experiments in us…

From elm.studio:

"We are bringing the simplicity and friendliness of Elm to hosting. No configuration. Just press publish."

And from the About Page on elm.studio:

"The ultimate goal is to produce a fun and simple programming language, with the kind support and camaraderie of people who like what we do and how we do it."

Very little information about what is the next step in Elm's life, or even whether they've actually left it... I guess the upcoming talk on StrangeLoop[1] may clear things up... his description on that talk hints at what he's up to:

"He lives in Denmark, working alongside his wife at elm.studio to keep Elm independent and interesting."

Elm may still be alive, just not publically for now.

EDIT: just found this while looking for more information:

https://iselmdead.info/

:D

[1] https://thestrangeloop.com/2023/the-economics-of-programming...

Re: Gren – an Elm fork

#96

Post by awestroke »

hombre_fatal wrote: post #35
hu3 wrote: post #34

Earlier quoted context omitted.

It's totally fine to run the project (or don't run) as the owner see fits and use it however one wants. But let's not pretend the project is actively maintained and there are no bugs. That's what klabb3 alludes to. Elm has this "this is fine" phenomenon where people like to pretend its a one-of-a-kind software that has no bugs doesn't even need a patch with bug fixes.

Do people pretend that? Or is it just an HN circlejerk that reports it be so? I'm a regular user of the Elm ecosystem, like the Slack/Discord, and everyone talks casually about Elm's bugs. In the #beginner channel it's just "Yeah oops that's def a known issue, but you can work around that with X." It's just that Elm is still a good tool despite its warts, and its bugs aren't catastrophic. Presumably that's the smokin…

No, it's that Elm fans defend the decision to never fix those bugs

Re: Gren – an Elm fork

#97

Post by Skinney »

nrabulinski wrote: post #91
Skinney wrote: post #74

Lead developer here. I think it’s a little misleading that the title of this post is «Gren - an Elm fork». While technically correct, I think there are many who will be dissapointed to find that Gren and Elm are incompatible languages. In addition to some syntax changes and improvements, Gren adds the support of a NodeJS target. It’s still early, so we don’t support all of the builtin APIs yet, but we’ll slowly get t…

Unrelated to Gren, but what happened to Stabel? It seemed like a very cool and interesting project yet when I wanted to read more about it, all the resources were down

Nice to see that people were interested in Stabel :D

I got a bit too ambitious with the type system, I think. At the very least, I got to a point where I got discouraged because the type system I wanted was difficult to implement, and I started to realize that there were a few problems with the design. At the same time, I was starting to feel that this may not actually be something I'd want to use in production.

On the flip side, I learned a whole lot about web assembly that I hope to put into Gren. I also felt a lot of pain with the lack of FileSystem APIs in Elm (which Stabel was implemented in). In a way, my work on Stabel triggered the work on Gren.

Re: Gren – an Elm fork

#98

Post by scns »

Skinney wrote: post #92
rapind wrote: post #84

Earlier quoted context omitted.

As someone who uses and is generally pleased with Elm (a large part of my product's UI is Elm) I could use more detail on what is different and especially why it is different. I did find a news post listing some differences, but it didn't really go into "why". A dedicated page outlining the differences / opinions on the changes would help me determine if this is a language I might use. Having a NodeJS (server) target…

No tuples: I found this to trade some convinience (no need to name anything)for worse refactoring (adding a value to a tuple or reordering the fields breaks everything, doing the same to a record doesn’t). I also improved pattern matching on records to make them more ergonomic. No automatic record constructors: same as the above, but in my experience it also confused beginners. I know of several that actively avoids…

> No tuples: I found this to trade some convinience (no need to name anything)for worse refactoring (adding a value to a tuple or reordering the fields breaks everything, doing the same to a record doesn’t).

Did you mean better refactoring?

Re: Gren – an Elm fork

#99

Post by scns »

_6efo wrote: post #65

Elm has a total toxic waste dump of a community, despite being IMO a pretty good language, so I'm leery of these offshoots and forks (there are a few others as well) especially because it seems like they're created by members of Elm's core team which is the epicenter of why the community is like it is.

https://news.ycombinator.com/newsguidelines.html

Re: Gren – an Elm fork

#100

Post by nativecoinc »

benatkin wrote: post #12
resoluteteeth wrote: post #11

Earlier quoted context omitted.

I don't understand. How does that make it not a fork?

It's a type of a fork but not the kind someone would expect after reading the headline. The FAQ has a similar description, but doesn't make the assertion that it's not a fork, which I disagree with: > Gren started as a fork of Elm. This is mostly considered to be an implementation detail, a way to speed up initial development. > It's not a goal of Gren to replace, or stay compatible in any way with, Elm. https://gren…

A fork where you diverge from the original is still a fork.

Most long-lived forks that I hear about are things that have developed into their own projects and have no intention of merging back to the original. Contrast with a short-term fork which will only live a few months and then will be hopefully be merged into the original; it will probably be so short-lived that people outside of the project won’t hear about it as a “fork” with its own distinct name.

A “fork” isn’t only making a GitHub fork so that you can make a PR against the original because you found a typo on the readme.

Post reply on HN