Live data from Hacker News

Gren – an Elm fork

gren-lang.org

41–50 of 129 posts

Re: Gren – an Elm fork

#41
post #16

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

Even worse, it checks the git history to make sure that... - 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/...

Correct me if I'm wrong, but that code seemingly only applies to kernel packages, i.e. packages which are made by the gren team [1]

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

Re: Gren – an Elm fork

#42
post #16

Earlier quoted context omitted.

Even worse, it checks the git history to make sure that... - 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/...

Correct me if I'm wrong, but that code seemingly only applies to kernel packages, i.e. packages which are made by the gren team [1] 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...

There are certain operations that only "kernel" packages are allowed to do. If that weren't the case, then this would indeed be little more than an obscure quirk.

Re: Gren – an Elm fork

#45
post #16

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

Even worse, it checks the git history to make sure that... - 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/...

That's only for their "kernel code" though, right? Huh, yeah, looks like it bans non-Elm(Gren) code [0].

And found a great bug where it broke their own code. [1]

[0]: https://github.com/gren-lang/compiler/blob/main/docs/kernel_...

[1]: https://github.com/gren-lang/compiler/issues/203

Re: Gren – an Elm fork

#46

Earlier quoted context omitted.

Correct me if I'm wrong, but that code seemingly only applies to kernel packages, i.e. packages which are made by the gren team [1] 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...

There are certain operations that only "kernel" packages are allowed to do. If that weren't the case, then this would indeed be little more than an obscure quirk.

Ah I see. So non-kernel packages do not have access to native modules at all? I believe in Elm native modules were still possible, just not publishing them to the package database. But in this case I guess you wouldn't be able to put a native module in a GitHub repository and then pull this in as a dependency, which is equally rubbish.

Edit: EdwardDiego's answer clarified this for me

Re: Gren – an Elm fork

#47
post #16

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

Even worse, it checks the git history to make sure that... - 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/...

It baffles me why anyone would fork Elm just to recreate one of it’s greatest mistakes.

Re: Gren – an Elm fork

#48
post #40
post #5

Earlier quoted context omitted.

For one, it's been over 2 years without an Elm release. And there are many open bugs untracked in GitHub. https://github.com/elm/compiler/issues Unrelated to your question but for those curious, here's a comparison between Gren and Elm : https://gren-lang.org/book/faq.html#what-are-the-differences...

One boring and banal problem I ran in to was that it will output text in yellow and some other colours which are hard to read on my white terminal background, and this is hard-coded and you can't disable colours (doesn't even disable with isatty). IIRC Evan didn't really want to fix it because "just use a dark background then". This is basically why I never used elm: because the compiler is hard to use as I struggle…

Fellow light theme user here. Forced terminal colors are the bane of my existence. I would kill for a contrast-aware terminal emulator that forces every character to have a minimum contrast with its background.

Re: Gren – an Elm fork

#49

Earlier quoted context omitted.

I mean the last commit for Elm core was in 2021. Changes require sign off that doesn’t seem likely from who is currently maintaining it. Why not fork it if you are interested in evolving ELM?

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 using Elm as a full-stack language. There are some notes and a few photos, but no video as far as I'm aware.

I'm not involved in the Elm community nor do I write it for a living though, so I'm only kind of aware of what's going on over in the Elm world.

Re: Gren – an Elm fork

#50
post #21

Earlier quoted context omitted.

Yeah sad. I appreciate the philosophy with slow careful releases and I also believe that people should be allowed to make unorthodox design choices in order to stay focused (or at least I’m not sure qualified to critique their choices). But, it seems like there’s a culture of taboo/fear/fanboyism which is clearly not healthy.

I don’t get what’s unhealthy about anything on that page. Elm’s trade offs are in plain sight. If you don’t want them, then you have plenty of warning. Frankly Elm has more of a problem with negative fanboying: people who have decided it’s not for them yet have to constantly show up to neener neener every time Elm appears on HN instead of just moving on. It’s very weird to me as someone who uses Elm daily. We get it.…

> people who have decided it’s not for them

Rather the opposite, actually. Elm had a lot of promise, and a lot of people really liked what they saw. I consider myself among them: language-wise Elm is pretty much my dream language, and I would love to use it in all my products.

But then I tried actually using it, and it turned out one of the core Javascript API wrappers was broken, and rather than accepting one of a dozen pull requests to fix it, they just nuked it instead and made it impossible to write the same wrapper yourself.

People keep talking about it not because they dislike it, but because they are grieving what could have been. Those tradeoffs and warnings weren't there when we first fell in love with the language.

Post reply on HN