Seems like the lead developer works for the company that rewrote www.vy.no [1] in Elm.
[1] “the largest transport provider in Norway” https://blogg.bekk.no/using-elm-at-vy-e028b11179eb
Gren – an Elm fork
101–110 of 129 posts
Re: Gren – an Elm fork
#102Earlier quoted context omitted.
> 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)
I don't know of this is meant to be sarcasm or earnest. In either case, it's wrong. Modern Windows will not run 16-bit DOS applications. But they did run (in various levels of compatibility) until 32-bit Windows was fully sunset (Feb 2020, Win10).
Re: Gren – an Elm fork
#103Earlier quoted context omitted.
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?
He means the tuple feature is convenient but makes refactoring harder than if you instead used a record.
Re: Gren – an Elm fork
#104Earlier 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…
I've long moved beyond Elm, but I'd be surprised is anyone really used reactor. It seemed so completely unfit for purpose and was almost immediately useless if your project was more than a single file. elm-live was simply a requirement no matter how much I tried to avoid adding in extra tooling.
Re: Gren – an Elm fork
#105Earlier 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…
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.
Re: Gren – an Elm fork
#106Earlier quoted context omitted.
It baffles me why anyone would fork Elm just to recreate one of it’s greatest mistakes.
Not even recreate, make the same mistake but even more intensely. It's impressive, in some ways.
I think this is an unfair opinion of Gren.
In the past, while using Elm, if you wanted to support some browser API that Elm didn't support yet you would have to fallback to kernel code. What Elm wanted: a core package that provided this low-level kernel package that provided typesafety at the Elm level. But as we know, this was a pipe dream because you could never contribute to Elm unless it was from the Elm dictator itself, or from his inner circle of cool people.
It seems like Gren is already ahead of this. Gren has community members actively working on the Websocket API to provide a typesafe core package with Kernel bindings.
The question is: will Gren keep being open to contributors that can provide kernel code.
Re: Gren – an Elm fork
#107Did 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…
> 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.
Re: Gren – an Elm fork
#108Elm 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.
Nah, I think it's fine.
Re: Gren – an Elm fork
#109Earlier 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…
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.
Re: Gren – an Elm fork
#110Earlier quoted context omitted.
Not even recreate, make the same mistake but even more intensely. It's impressive, in some ways.
I think this is an unfair opinion of Gren. In the past, while using Elm, if you wanted to support some browser API that Elm didn't support yet you would have to fallback to kernel code. What Elm wanted: a core package that provided this low-level kernel package that provided typesafety at the Elm level. But as we know, this was a pipe dream because you could never contribute to Elm unless it was from the Elm dictator…
That’s the plan