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

31–40 of 95 posts

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

#31

Post by troupo »

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…

ReasonML crippled themselves, too, by splitting the already tiny community between Reason and ReScript

Here's a good (neutral!) write-up: https://ersin-akinci.medium.com/confused-about-rescript-resc...

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

#32

Post by wryoak »

datadeft wrote: post #8

The website tells the full story: https://elm-lang.org/ © 2012-2021 Evan Czaplicki

And right above that line is the compiler source which Evan said people should feel free to fork and publish as long as they don’t name it something confusing and divisive like Elm+

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

#33

Post by josephcsible »

terminatornet wrote: post #28
ordinaryradical wrote: post #24

Earlier quoted context omitted.

Reason is a lovely, OCaml-esque language in the same functional vein, but I would say Gren feels like a great spiritual successor to Elm. https://gren-lang.org/

along those lines, Zokka is a fork of elm that appears to be mostly dedicated towards bug fixes that Evan (the creator of elm) refuses to acknowledge or merge. https://github.com/Zokka-Dev/zokka-compiler edit: there's also Roc, https://www.roc-lang.org/ , a language started by Richard Feldman who I believe was a former elm core team member. I think Roc aims to accomplish different things than elm, but definitely feel…

The commitment to bidirectional compatibility means that Zokka can't fix the problem that GGP was talking about.

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

#34

Post by klabb3 »

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 would recommend steering clear of [Go] for years, due to their decision to allow their own `map` type be a generic[2] type but no user-defined types could be[3]

I think this is very, very different. First because Go didn’t have a cultish purist aversion to generics, banning people, going after them even outside of community spaces. But on a technical side, maps (and slices and channels) were not gated to be used by std, they were publically available to anyone. Not having generalized a feature is not the same as banning it. There was not even Go syntax to express it. Same as arrays in C, no?

That said, I’m not challenging the recommendation to stay away or not - generics was (and still is, may I add!) quite a pain point with the language. I’m personally quite invested for other reasons (concurrency, networking, std lib), but people come to different conclusions naturally.

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

#35

Post by wryoak »

ddellacosta wrote: post #14

I wouldn't bother with Elm. Among other things: https://www.reddit.com/r/programming/comments/fxvlow/why_im_... PureScript ( https://www.purescript.org ) on the other hand is very nice.

PureScript made some ergonomically painful decisions (I value the logic behind their implementation of tuples but not having to use them in such a way), but I think the biggest point against it is how Haskell is moving into that space via JS and WASM compiler targets and bringing along its broader user base and library support

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

#36

Post by ordinaryradical »

josephcsible wrote: post #27
ordinaryradical wrote: post #24

Earlier quoted context omitted.

Reason is a lovely, OCaml-esque language in the same functional vein, but I would say Gren feels like a great spiritual successor to Elm. https://gren-lang.org/

Gren is a fork, not a spiritual successor. And not only did it not fix that problem, it made it worse: https://news.ycombinator.com/item?id=36275171

Yeah, I just read this further down in this topic. Really bummed about it, Elm always seemed so promising, and I thought a healthy fork was what was needed.

I just don’t understand the reasoning for this choice.

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

#37

Post by ISV_Damocles »

matsemann wrote: post #29
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…

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

It is impossible if you're being responsible. You don't choose a technology that could potentially block you from solving problems in the future unless it brings a huge value to you.

Elm's value proposition is mostly being a functional language with an opinionated MVU library baked in, so you can reproduce that value with a better functional language and selecting a similar MVU library in that other language, which means it should never actually cross the value bar above the risk it brings if you need a browser feature it doesn't support and actively prevents you from accessing.

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

#39

Post by huy-nguyen »

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…

If you’re a front-end developer, you should checkout ReScript[1], supposedly a JS-oriented successor of ReasonML and developed by the ReasonML team.

[1] https://rescript-lang.org/

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

#40

Post by baobabKoodaa »

matsemann wrote: post #29
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…

> 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 also had the pleasure of maintaining an Elm codebase. It was filled to the brim with state update bugs. You could never trust what you saw in your browser. Nobody in the team understood how the codebase worked. I spent days implementing some extremely simple changes, which barely worked (to the same standard as the rest of the codebase). Never again.
Post reply on HN