Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Road to Elm 1.0

elm-lang.org

Post reply on HN
Print view View original

181–190 of 192 posts

Re: Road to Elm 1.0

#181

Post by 1-more »

pyrale wrote: post #136
1-more wrote: post #83

Earlier quoted context omitted.

say more! Is it that it has typeclasses but they're closed?

It is that even without an open typeclass system, these specific typeclasses have been a common request for a long while. I have worked at a few elm places, there is always a dict-for-everything dependency or local implementation.

Haha we may have worked together. Equatable has been a theoretically huge, actually OK hole in my opinion because it _can_ lead to runtime crashes but never has in any code I've written (\_ -> () == \_ -> () is a runtime crash). So I'm glad to see something more robust than "just don't do that." And "hashable" as the real thing you need to implement Set/Dict is a good idea imo. I'm sympathetic to keeping "comparable" closed and even smaller than it is for the reasons in this discussion [0]. In my perfect world, String would not be comparable as-is because string comparison should be locale dependent. Right now string comparison just ends up using JS's But I agree with you that the current solutions for Set/Dict all have one problem or another: You can use elm-sorter-experiment [1] but then you are writing a sort function and passing it around and maybe you don't want the overhead of that. You can switch to the Lamdera compiler and use containers [2] but then it's a different compiler and a you need to tweak your options slightly to compile an Elm project as an Elm project in it and it could get out of sync with the Elm compiler (extremely unlikely though). You can use any of the list/dict implementations that are really just lists with O(n) everything under the hood. So maybe this hashable type is going to make things better, idk.

[0] https://github.com/elm/compiler/issues/774#issuecomment-3472...

[1] https://github.com/rtfeldman/elm-sorter-experiment

[2] https://github.com/lamdera/containers/tree/main

Re: Road to Elm 1.0

#182

Post by 1-more »

lolc wrote: post #176
1-more wrote: post #82

Earlier quoted context omitted.

You can also do lunatic things like overload the `Object` prototype and get synchronous FFI by encoding then decoding an object. I do this at work to get locale-aware sorting. I know you know this, but it'll be news to others in the thread.

Haha, yeah I didn't realize there would be a monkey patch route to FFI in Elm. Can't control the runtime. Is there a good read up on this technique?

Slightly important point: it's still safe FFI! Everything that crosses the JS/Elm boundary has to be encoded/decoded from serialized JS Objects. So it's hacky BUT it's not actually unsafe, which is kind of funny. I have an example where I use it to effect locale-aware sort. This repo is a benchmark test of that: https://github.com/perkee/elm-js-sort-ffi-speed-test/tree/ma...

Re: Road to Elm 1.0

#183

Post by 1-more »

desireco42 wrote: post #160
ethagnawl wrote: post #75

Earlier quoted context omitted.

For whatever it's worth, I've found Gren to be a very capable successor with an active and helpful community.

Never heard of it and I am glad you mentioned it, thanks. Already homepage and examples look familiar and welcoming.

If you'd like an incomplete list of everything that's downstream from Elm, I made one the last time a TEA library got to the front page here: https://news.ycombinator.com/item?id=47678424 The creator of Derw shows up one comment later to remind me of one that I was forgetting.

Re: Road to Elm 1.0

#184

Post by lolc »

1-more wrote: post #182
lolc wrote: post #176

Earlier quoted context omitted.

Haha, yeah I didn't realize there would be a monkey patch route to FFI in Elm. Can't control the runtime. Is there a good read up on this technique?

Slightly important point: it's still safe FFI! Everything that crosses the JS/Elm boundary has to be encoded/decoded from serialized JS Objects. So it's hacky BUT it's not actually unsafe, which is kind of funny. I have an example where I use it to effect locale-aware sort. This repo is a benchmark test of that: https://github.com/perkee/elm-js-sort-ffi-speed-test/tree/ma...

Great hack, thanks! And yea I was missing some native string api when I abandoned Elm at 0.19.

Re: Road to Elm 1.0

#185

Post by song_synth »

1024bits wrote: post #134
song_synth wrote: post #100

Any insight on comparing Elm to Yew? I once wrote a frontend webapp with Elm. And with backend server in Clojure, it made as much sense as Elm five years ago, right? :) For the past two years I've instead used Yew, a rust crate for building UIs. It can look like react or like Elm, it's up to you for how you yew s it ;0) My latest app uses The Elm Architecture in Yew. It has been fantastic. I think the biggest benefit…

I don't know about Yew but I've been using Iced 0.14 which is also a Rust crate inspired by the Elm architecture. It seems like Yew is specifically geared towards web applications, which I suppose is in some ways closer to the original Elm project. What is your app? Is it intended for personal use, or commercial?

Iced looks nice! It would be super sweet to have a desktop + web cli with a mostly-shared rust codebase.

You are definitely welcome to use my app, it is a music generation and education website! Monic Theory can be found here :)

https://monictheory.com

Re: Road to Elm 1.0

#186

Post by 1024bits »

song_synth wrote: post #185
1024bits wrote: post #134

Earlier quoted context omitted.

I don't know about Yew but I've been using Iced 0.14 which is also a Rust crate inspired by the Elm architecture. It seems like Yew is specifically geared towards web applications, which I suppose is in some ways closer to the original Elm project. What is your app? Is it intended for personal use, or commercial?

Iced looks nice! It would be super sweet to have a desktop + web cli with a mostly-shared rust codebase. You are definitely welcome to use my app, it is a music generation and education website! Monic Theory can be found here :) https://monictheory.com

Nice! I'm quite the beginner when it comes to music production and theory (took me a while to even figure out "Audition" means "Listen"), so I couldn't make full use of this site, but I like ideas presented in your about section. The website is quite functional, which is nice to see from a Rust base.

I'm interested in looking at more commercial products made in Rust, they tend to be far more polished than what I can stumble upon in Github (and are thus a nice showcase of what a bit of polish can do for these frameworks).

Re: Road to Elm 1.0

#187

Post by goosejuice »

Aurornis wrote: post #152
goosejuice wrote: post #98

Earlier quoted context omitted.

Were people forced to use elm prior to a 1.0 release or something? Is Evan being accused of baiting people with a lovely experience and then bailing? I'm not really familiar, so maybe the ball was dropped in some kind of contract I'm not aware of. If not, the expectations you and many have here seem pretty unreasonable. There's room for projects like Elm. Not every PL has to meet the demands of every single non payin…

> Were people forced to use elm prior to a 1.0 release or something? Obviously not, but for a short while it felt like Elm evangelization was everywhere. Ironically, the small group pushing it so hard at the company I was with at the time were arguing that it was very stable and production ready, despite being pre-1.0. That argument switched for the 0.19 release, when it was argued that it was still early and changin…

Well surely evangelization doesn't absolve a technical leader for choosing to rely on a BDFL project that's pre 1.0.

People are welcome to their opinions, but I don't see a rug pull, I see a grad student who created a project that people enjoyed and a few companies offered to fund. Evan clearly wanted to maintain control over direction and stepping away from open source is completely acceptable and not uncommon for the very reasons on display here. People have completely unreasonable expectations from maintainers of free software.

Re: Road to Elm 1.0

#188

Post by 1-more »

discardable_dan wrote: post #167
berns wrote: post #145

Earlier quoted context omitted.

The compiler has hard coded domains that control who can use certain features. For example, custom operators aren’t allowed, but Evan is able to use them.

Why.... ?

The reasoning for removing custom infix operators is explained here https://gist.github.com/evancz/769bba8abb9ddc3bf81d69fa80cc7...

I encourage you to read the whole thing, but the standout quote for me is near the end:

> One thing I learned from discovering The Elm Architecture is that it is really lovely to be able to show up in any codebase and know what is going on. I think custom operators detract from that enough that they are not worth it for the whole ecosystem, even if they are great for specific individuals.

Having talked to people at work who had to remove custom operators when they upgraded from 0.18 to 0.19, they initially didn't love dropping them, but getting rid of the syntax cliff for new hires at the expense of terseness for the old hands was a decent tradeoff. Personally, I find it can be easy in an ML family language to get a bit wrapped around the axle trying to write the most terse, pointfree implementation of something.

Re: Road to Elm 1.0

#189

Post by rofrol »

epolanski wrote: post #125
bbkane wrote: post #54

I think of Elm more as an incredibly influential research language these days. It's very focused, there's no public roadmap or official support and the leadership (which is far as I can tell is just Evan) is uninterested in most (any?) community building or core team building. But MAN is it nice to work in. This has resulted in several forks/spin-offs. At the recent Gleam conference, Louis Pilfold joked that every El…

I'm one of those. I extended the language to support a bunch of niceties (essentially supporting a proper error channel and dependency injection through erasable sum types). Elm is a nice language, but Ewan has no interest in building anything truly useful and the whole administration of the language is s disaster.

Can you share your git repo link?
Post reply on HN