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

81–90 of 129 posts

Re: Gren – an Elm fork

#81

Post by jgilias »

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…

As the sibling commenter says, maybe it’s worth reconsidering the approach somewhat?

As in, I do get the reasoning, but there are valid situations where one might need to do this for their own reasons. So maybe there’s some way to make it clear that you shouldn’t be doing this, yet still narrowly allow it. A non-default CLI flag, a scary compilation warning, maybe needs to use some special keyword to use code like that. Like how you need to use ‘unsafe’ in Rust to interact with C code directly.

Otherwise, thank you for working on this! An Elm inspired language that’s open to community development is something the world needed :-D

Re: Gren – an Elm fork

#82

Post by Skinney »

josephcsible wrote: post #79
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…

Why couldn't you make it just a warning, or even require a command-line flag for it? As it is now, even trying to write and test a PR for any such code requires modifying the compiler.

The kernel code API is quite… unfinished. It isn’t documented, it performs no validation and it crashes the compiler when written incorrectly. It really isn’t ready for general use. It’s also expected to break in the next few releases.

I will have to revisit kernel code at some point in the future, probably when looking into WASM (which will break all uses of kernel code), but I have other, more important, features to add first.

Re: Gren – an Elm fork

#83

Post by Skinney »

jgilias wrote: post #81
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…

As the sibling commenter says, maybe it’s worth reconsidering the approach somewhat? As in, I do get the reasoning, but there are valid situations where one might need to do this for their own reasons. So maybe there’s some way to make it clear that you shouldn’t be doing this, yet still narrowly allow it. A non-default CLI flag, a scary compilation warning, maybe needs to use some special keyword to use code like th…

Yeah. I understand the need for this, but I’m also very hessitant to break guarantees on mutation and other side effects. It’s a tricky problem.

It will be looked at pre 1.0.

Re: Gren – an Elm fork

#84

Post by rapind »

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 is definitely interesting.

Re: Gren – an Elm fork

#85

Post by lf-non »

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

Re: Gren – an Elm fork

#86

Post by quickthrower2 »

afavour wrote: post #38
Fitzero wrote: post #3

Obligatory https://iselmdead.info/

> 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! Stockholm Syndrome at work

Yes, Microsoft have made lots of updates but your 16 bit DOS game will still run. (Elm cannot run old Elm programs but to be fair Elm is on a prerelease alpha < 1.0 version)

Re: Gren – an Elm fork

#87

Post by silasdavis »

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

I guess you have to get over the name...

Re: Gren – an Elm fork

#88

Post by ctenb »

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.

VScode terminal has this

Re: Gren – an Elm fork

#89

Post by quickthrower2 »

hombre_fatal wrote: post #26
klabb3 wrote: 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.…

I think some negative fanboyism is because Elm promises a lot, and also delivers a lot of promises but there are some choices that sort of rub against our intuitions about software. Principle of least surprise.

Example 1: No typeclasses? Fine. But why is there comparable, which quacks like a typeclass and why can only kernel code use it? Practical implication: sorting, which is a bread and butter language/library feature is messy to code and inefficient at runtime.

Example 2: Why isn’t negative number pattern matching just fixed based the principle of least surprise and as a clear bug rather than gaslighting those who found 10 seperate examples of why pattern matching (which is a sugared if/switch) should blow up at compile time with negative numbers.

None of this makes sense. So I think it is good to warn people who are about to invest a lot of time. There will be edges where you wont have fun.

Finally; whether the api gets broken next month or there will be zero releases this decade is not clear. It is not a language where you can reason about it’s future, like maybe you can with JS, Java, Python, C# etc.

Elm is an experimental language. It is also production ready. That intersection is rare and I think that is what causes issues.

Haskell spent a long time as a toy before people made it a production language. And now it is no longer experimental on the whole. No benedict is going to do a 180 on Haskell. You are just gonna get more GHC language extensions for experimenting with ideas. I think this is better/more mature approach.

Re: Gren – an Elm fork

#90

Post by xupybd »

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

That's not the most constructive way to word that.
Post reply on HN