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

121–129 of 129 posts

Re: Gren – an Elm fork

#121

Post by [deleted] »

yawaramin wrote: post #52
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…

So much for the vaunted 'friendly compiler messages' that Elm is so praised for!

[deleted]

Re: Gren – an Elm fork

#122

Post by hombre_fatal »

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.

On the other hand, this comment shows the clown car of HN discourse: everything that doesn’t make the trade offs that you want is a literal dumpster fire end of discussion.

Re: Gren – an Elm fork

#123

Post by Jeff_Brown »

G4BB3R wrote: post #67
Jeff_Brown wrote: post #51

Earlier quoted context omitted.

No tuples?! What if you want a function to return, say, a number and a string? Are lists heterogeneous? That defeats a lot of the safety a type system can offer.

You can still use records and custom types for this case.

Ah, of course! Those are as expressive and safer. Thanks.

Re: Gren – an Elm fork

#124

Post by Skinney »

toastal wrote: post #113
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?

There’s no technical reason for it to be bound to github, it just haven’t been a priority.

Contributions welcome.

Re: Gren – an Elm fork

#125

Post by m8s »

vbezhenar wrote: post #105
m8s wrote: post #49

Earlier quoted context omitted.

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…

But bugs have to be fixed. You can't claim that popular non-trivial project is alive without constant commits. Even if no new features are added. I can see many issues about compiler crashes, etc. Sounds like not mature project.

That’s fine, but that’s just your opinion. A lot of people use Elm in production and don’t have issues with it. I’m neutral on Elm. I think it’s a cool language but I don’t use it. I’m not convinced that “constant commits” signal the life of a project though.

Re: Gren – an Elm fork

#126

Post by josephcsible »

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?

The articles linked by each of those posts contain numerous references to "native modules" and "kernel code". In this context, those things mean the ability to call back into JavaScript from Elm. The ability to do this exists in Elm, but it's locked down so you can't use it.

Re: Gren – an Elm fork

#127

Post by Skinney »

josephcsible wrote: post #126
brabel wrote: post #93

Earlier quoted context omitted.

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?

The articles linked by each of those posts contain numerous references to "native modules" and "kernel code". In this context, those things mean the ability to call back into JavaScript from Elm. The ability to do this exists in Elm, but it's locked down so you can't use it.

To be fair: you can definitely call JS from Elm/Gren using ports, which exposes the JS world as an async service you can call. This seperation means you lose none of the guarantees of the language, while being able to communicate with the outside world. Kernel code is completely unprotected, and would allow mutations, exceptions and side-effects in "Elm world".

The main problem with ports is that (1) it's an async API, which can be awkward for certain operations and (2) you cannot define a package that contains ports.

Re: Gren – an Elm fork

#128

Post by plazma »

hu3 wrote: post #34
hombre_fatal wrote: post #26

Earlier quoted context omitted.

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

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.

This is what I don't like about it. Other then that Even is running things differently and maybe it's not for you, but some people really like it and maybe some more will.

Take a look at https://elm.studio/about.html, please read comparison there. Elm does not want to be mainstream, people should really understand that.

Re: Gren – an Elm fork

#129

Post by jlokier »

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.

iTerm2 on the Mac has this. It's a "minimum contrast" slider from 0 to 100% which does what you'd expect. It's nice that it's adjustable.

Windows Terminal has something like this, but finds a way to screw it up. I use Windows Terminal for development over SSH in my current job. It has a checkbox "Automatically adjust lightness of indistinguishable text" (non-adjustable), but it doesn't seem to change the cursor. Whatever colour I set the cursor to, whatever shape, and even with blinking, the cursor is nearly invisible in some of the terminal tools I use, when it is close to the background colour. Even ancient terminal emulators pick a contrasting colour for the cursor. It is an obvious requirement, and Windows Terminal does the opposite, so you can see text but not the cursor.

Post reply on HN