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

111–120 of 129 posts

Re: Gren – an Elm fork

#111

Post by oxnrtr »

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…

Stockholm syndrome. You know ... normal people in normal projects would just fix the bugs?

Re: Gren – an Elm fork

#112

Post by sapiogram »

Skinney wrote: post #75
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 )?

No. In fact I added some code that still enforces this with the Git-based package manager. I know a lot of people got burned by this when Elm added this enforcement, and that seeing it here in Gren can cause a lot of eyerolls. However. The greatest feature of the language is the absence of mutation and user-defined exceptions, and managed side-effects. Making the kernel code api accessible to everyone would introduce…

Regardless of the details here: Thank you so much for taking the time to come here and explain your decisions, without getting offended or overly defensive.

Re: Gren – an Elm fork

#113

Post by toastal »

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…

Unlike Elm, does Gren allow community packages hosted outside of Microsoft GitHub or is that same lock-in retained?

Re: Gren – an Elm fork

#114

Post by [deleted] »

brabel wrote: post #93
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?

[deleted]

Re: Gren – an Elm fork

#115

Post by EscapeFromNY »

ctenb wrote: post #88
EscapeFromNY wrote: post #48

Earlier quoted context omitted.

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.

VScode terminal has this

I just tried it and it's exactly what I was hoping for! Unfortunately though the terminal can't run standalone: https://github.com/microsoft/vscode/issues/34442

Re: Gren – an Elm fork

#116

Post by lolinder »

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…

People absolutely pretend that! This whole subthread spun of from a discussion of https://iselmdead.info/, which says (emphasis added):

> Elm’s release cycle is (very) slow on purpose. ...

> While the language doesn’t get frequent updates (and that’s a good thing!), ...

> Why is it a good thing that Elm doesn’t get frequent updates? First of all, it means your code will last a long time! It also means the language is very stable, because features are carefully thought out before being implemented.

I have no problem with people enjoying Elm and acknowledging the bugs. I really dislike that this site gets posted every time people point out that there hasn't been an update in four years. A four-year break between updates is not "all part of the plan". It's not a slow release cycle. It's a sign that the creator ran out of steam but didn't want to delegate to a successor.

You seem to be reasonable in your approach to Elm, and that's great. But there absolutely is a contingent that tries to pretend that this four-year hiatus is part of Evan's master plan for Elm and is "a good thing", and it's reasonable for the HN crowd to call that out as problematic.

Re: Gren – an Elm fork

#117

Post by arp242 »

EscapeFromNY wrote: post #48
arp242 wrote: post #40

Earlier quoted context omitted.

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.

You can probably hack suckless' st terminal to do this without too much effort (just checking for \x1b[41m and \x1b[100m and the reverse attribute is probably enough, not many use the 256 colours or true colours to set the background, although you can make it as complex as you want).

For 99% of things it's not really an issue so I never bothered: you can either configure the colours or you can just disable them fairly easily.

Re: Gren – an Elm fork

#118

Post by tasuki »

oxnrtr wrote: post #107
Skinney wrote: post #75

Earlier quoted context omitted.

No. In fact I added some code that still enforces this with the Git-based package manager. I know a lot of people got burned by this when Elm added this enforcement, and that seeing it here in Gren can cause a lot of eyerolls. However. The greatest feature of the language is the absence of mutation and user-defined exceptions, and managed side-effects. Making the kernel code api accessible to everyone would introduce…

> my memory from the pre 0.19 days of Elm tells me that this made for a worse experience overall My memory tells me that 0.19 literally killed the language.

As is often the case with one's memory, it bears a grain of truth but distorts reality. I've been using Elm 0.19 for side projects and enjoy it.

Re: Gren – an Elm fork

#119

Post by tasuki »

oxnrtr wrote: post #109
brabel wrote: post #95

Earlier quoted context omitted.

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 actuall…

> Why is it a good thing that Elm doesn’t get frequent updates? First of all, it means your code will last a long time! It also means the language is very stable, because features are carefully thought out before being implemented. What an absolute clown car.

Actually I think that's a reasonable stance. Not everyone wants to use the newest and greatest JavaScript framework which is will be completely reworked in six months because there's a need for a newer and greatester version. The speed of evolution of JavaScript frameworks is amazing, yet they're all still worse thought out than Elm.

Re: Gren – an Elm fork

#120

Post by thiht »

lf-non wrote: post #85

For folks who don't care as much about iron-clad protection against mutability and side-effects, but want an elm-ish language that prioritizes functional code, derw is an interesting upcoming alternative. It also targets good interop with typescript which is a big plus in current state of frontend ecosystem. https://docs.derw-lang.com

That’s a terrible name.
Post reply on HN