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

Learning Elm by porting a medium-sized web frontend from React (2019)

benhoyt.com

Post reply on HN
Print view View original

81–90 of 95 posts

Re: Learning Elm by porting a medium-sized web frontend from React (2019)

#81

Post by lf-non »

kriiuuu wrote: post #67
lf-non wrote: post #65

Earlier quoted context omitted.

Are you actually using this in a non-trivial application? The recurring complain I hear about scala are the bad compile times. I haven't used the language much, so not sure if this only applies to libraries that heavily use compile time metaprogramming. But I really love that with modern tooling we can get a sub-second editor->browser feedback loop even for a three year old medium-large project on modern hardware. Th…

I have a medium sized project with it and the initial compile can be slow, however every recompile usually has the page updated as I switch from my editor to it. Not as fast as TS, but worth it for the much better programming language. Tyrian also makes it trivial to set up hot-reload with preserved state.

Ok, this is interesting. I'll try this out in a small project.

Re: Learning Elm by porting a medium-sized web frontend from React (2019)

#82

Post by marc136 »

vsuperpower2020 wrote: post #79
matsemann wrote: post #29

Earlier quoted context omitted.

> making it impossible to actually use the language in production Just FUD. I've been on a big team writing a webapp used by hundreds of thousands each day. While it's not necessarily my own first choice, it was great and the least error prone piece of software I've written in my career.

I've seen the word FUD 4 times on this page already. The "elm defense force" sounds a lot like cryptobros defending their rug pull. It's such an odd piece of language to adopt over people not liking some javascript compiler for perfectly valid reasons.

Funny that you have this impression.

To me it looks more like the elm-haters are out in force and the Elm users don't participate anymore on this site.

Many hateful comments here below a historic post prompted me to create a new account after a detox phase of >10 years.

So far I try to correct a false statement in the (as of writing this) top comment [1] or add a more neutral view [2]. And maybe I will add more of my personal opinion in the future - or participate in other interesting topics depending on my mood.

[1]: https://news.ycombinator.com/item?id=39555542 [2]: https://news.ycombinator.com/item?id=39556395

Re: Learning Elm by porting a medium-sized web frontend from React (2019)

#83

Post by tasuki »

marc136 wrote: post #71
josephcsible wrote: post #16

For anyone new to Elm, remember that as of version 0.19, unless your project is one of the Elm core team's pet projects, you'll have a severely restricted feature set available. See https://news.ycombinator.com/item?id=22821447 , https://news.ycombinator.com/item?id=17842400 , and https://news.ycombinator.com/item?id=16510267 for details.

For anyone new to Elm, please know that you have a stable language with no major changes since 2018 and no official release since end of 2019, see https://iselmdead.info and decide if that is a bad or a good thing for you. And if you are thinking of starting now, you should not focus on what undocumented feature (or hack) was taken away in 2018 that allowed injecting arbitrary JavaScript code that easily broke all gu…

The "no updates for past five years" is my favourite feature of Elm.

I have some five or so projects written in Elm and enjoy every time I don't have to upgrade them because no new version was released!

Re: Learning Elm by porting a medium-sized web frontend from React (2019)

#84

Post by lolc »

fulafel wrote: post #80
lolc wrote: post #64

Earlier quoted context omitted.

In my case, it was a regex supplied by the user. Elm 0.18 had no support for constructing a regex at run-time. So I made a package that wraps native RegExp. When 0.19 was released, I couldn't upgrade because of those 5 lines. The regex package eventually got regex.fromstring(). So I could've upgraded. But at the time I was bumping against limits accessing Intl and I really hated the prospect of begging some maintaine…

As a Elm non-user, naive question: would it be possible to use the JS interop (ports) for this, at cost of some clunkiness?

Yes the answer is always ports when this topic comes up. Unfortunately one can only pass some basic types through ports. Passing a RegExp or an Intl.DateTimeFormat is not possible. It needs a wrapper on the Elm side, and the Elm people decided I can't be trusted to write this wrapper for me.

Back then if I wanted to search a list of strings for entries that match a regex supplied at run-time, I'd have to pass the whole list through a port, filter it outside, then pass it back in. Rather than just using the filter function. Ports are asynchronous messaging which means I have to restructure the whole code and wait for a state change when the filtered list is returned.

Let me cite the Elm docs on ports[1]: "Definitely do not try to make a port for every JS function you need."

So! Where does that leave me? Unsupported, that's where. Because I need a JS function. In 0.18 unsupported was fine. They broke it for 0.19 and the project died. Maybe it was dying of other causes anyway, but that one action sure drove people away.

[1] https://guide.elm-lang.org/interop/ports

Re: Learning Elm by porting a medium-sized web frontend from React (2019)

#85

Post by lolc »

savanaly wrote: post #66
lolc wrote: post #64

Earlier quoted context omitted.

In my case, it was a regex supplied by the user. Elm 0.18 had no support for constructing a regex at run-time. So I made a package that wraps native RegExp. When 0.19 was released, I couldn't upgrade because of those 5 lines. The regex package eventually got regex.fromstring(). So I could've upgraded. But at the time I was bumping against limits accessing Intl and I really hated the prospect of begging some maintaine…

Yeah, I really feel this a good way to divide developers into two types. There are those like me, to whom the philosophy of discourage foot guns systematically sounds kind of brilliant. To put it in flattering terms, it's pay a short term cost for the long term and hard-to-perceive but very real benefits (making certain categories of errors completely extinct). To put the other side in flattering terms: they're not l…

The Elm people themselves worked with the impure browser api all the time. They just don't want me to do it. So it's not even a foolish consistency but just base gatekeeping. Turns me right off.

If you want to divide into two camps how 0.19 was received I'd say it's people who were maintaining a substantial Elm project on the one side and people who weren't on the other. Maybe if you're carrying a torch don't drop it on the ecosystem.

Re: Learning Elm by porting a medium-sized web frontend from React (2019)

#86

Post by ghusbands »

matsemann wrote: post #49
savanaly wrote: post #41

Earlier quoted context omitted.

Out of curiosity, what did you try to do that you hit that issue right away? I've been writing Elm apps as side projects for years, and never even come close to the kernel thing being a problem. My apps are mostly graphically undemanding games and helper tools. What are the types of applications where this becomes an issue right away?

Most likely they didn't understand Ports and immediately wanted to reach for kernel stuff.

It's odd and rude to declare someone incompetent from so little information. Especially when the same problem is widely reported by other developers.

Re: Learning Elm by porting a medium-sized web frontend from React (2019)

#87

Post by ghusbands »

cdelsolar wrote: post #75
ISV_Damocles wrote: post #17

The year in this link is very important. In the following year, the Elm team decided to not pay attention to the maxim "perfect is the enemy of good" and crippled their FFI story, making it impossible to actually use the language in production[1]. I would recommend to steer clear of a language that makes these sorts of decisions -- that certain features are off-limits to the regular developer because they can't be tr…

I’ve been working with Go for 10 years and I have no idea what you mean by maps being generic before generics came along, nor did maps ever cause me to have over-verbose code bases. The links didn’t seem to help.

Trying to summarise what they were likely saying: Not having generics makes code verbose because you end up copying and pasting your library code to make it handle different types. The complaint about maps being generic was that the Go team clearly saw a need for generics (as they implemented them for maps and some other types) but decided that others wouldn't need them. So they had one rule for them and another rule for everyone else, which people don't like.

Re: Learning Elm by porting a medium-sized web frontend from React (2019)

#88

Post by marc136 »

lolc wrote: post #64
savanaly wrote: post #41

Earlier quoted context omitted.

Out of curiosity, what did you try to do that you hit that issue right away? I've been writing Elm apps as side projects for years, and never even come close to the kernel thing being a problem. My apps are mostly graphically undemanding games and helper tools. What are the types of applications where this becomes an issue right away?

In my case, it was a regex supplied by the user. Elm 0.18 had no support for constructing a regex at run-time. So I made a package that wraps native RegExp. When 0.19 was released, I couldn't upgrade because of those 5 lines. The regex package eventually got regex.fromstring(). So I could've upgraded. But at the time I was bumping against limits accessing Intl and I really hated the prospect of begging some maintaine…

> So I made a package that wraps native RegExp. When 0.19 was released, I couldn't upgrade because of those 5 lines. The regex package eventually got regex.fromstring(). So I could've upgraded.

The last commit to the regex package was in May 2018, and Elm 0.19 was released later in August. https://github.com/elm/regex/commits/1.0.0/

So it seems like by the time of the official release you could have replaced your five lines with `Regex.fromString`.

But the missing Intl API is definitely a huge pain, and I understand that you were switching away if you needed it extensively. Or expected to want other sync APIs wrapped.

A common way to solve something like this is with proxy objects like in https://github.com/anmolitor/intl-proxy but it does not give access to every feature in a nice way.

I went the route of least resistance and built the Elm compiler without the Kernel code check. But in the past few years I hardly needed that anymore.

Re: Learning Elm by porting a medium-sized web frontend from React (2019)

#89

Post by marc136 »

fulafel wrote: post #80
lolc wrote: post #64

Earlier quoted context omitted.

In my case, it was a regex supplied by the user. Elm 0.18 had no support for constructing a regex at run-time. So I made a package that wraps native RegExp. When 0.19 was released, I couldn't upgrade because of those 5 lines. The regex package eventually got regex.fromstring(). So I could've upgraded. But at the time I was bumping against limits accessing Intl and I really hated the prospect of begging some maintaine…

As a Elm non-user, naive question: would it be possible to use the JS interop (ports) for this, at cost of some clunkiness?

Yes, ports or custom elements are the recommended options, https://github.com/elm-community/js-integration-examples

There are a bunch of other options/workarounds/hacks depending on the need. E.g. using getters or creating proxy objects https://github.com/anmolitor/intl-proxy, or event listeners, or postprocessing of the generated JS code, but those shouldn't be the first idea to reach for.

Re: Learning Elm by porting a medium-sized web frontend from React (2019)

#90

Post by marc136 »

ISV_Damocles wrote: post #51
matsemann wrote: post #47

Earlier quoted context omitted.

Now you're moving the goalpost. You said it was impossible to use in production. Which is clearly wrong.

I am just clarifying why I consider it impossible. Production is not some place you're supposed to cowboy code, but instead have a reasonable expectation that you will be able to continue supporting it for as many years as it operates, and it's impossible for anyone to responsibly use technology with known limitations that have bitten other real engineering teams that they can find zero workarounds for. If you don't…

Zero workarounds seems overly dramatic, here are a few: https://news.ycombinator.com/item?id=39567011

If you want to rely on them for every possible future requirement or rather want to pick another tool is another question :D

Anyways, just building the compiler without that check was also not that hard.

Post reply on HN