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

71–80 of 95 posts

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

#71

Post by marc136 »

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 guarantees of the language https://discourse.elm-lang.org/t/native-code-in-0-19/826 but rather if Elm fits your current (and maybe future) needs. If it does not, keep looking for alternatives.

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

#72

Post by paradox460 »

matsemann wrote: post #50
hombre_fatal wrote: post #45

Earlier quoted context omitted.

Jeez, at some point you folks who don’t like Elm’s decisions have to leave the theater so the rest of us can enjoy the show. If you think a cult of personality is bad, you aren’t appreciating how much worse is, to the rest of us, the cult of anti-cheerleaders on every post that mentions Elm. For years now any time someone wants to read about Elm, they have to hear from the same few HNers who don’t even use it yet ref…

I'm quite curious what Elm triggers so in people, that they years later actively hunts down discussions about it to interject their negativity.

They damaged the illusion of the "B" in "BDFL" with their changes in 19. Open-Source programmers like to believe that their toolchains and whatnot are egalitarian, and treat everyone as equals. Many accept the idea that the STDlib will be "more special," because its included in every copy of the language. This pill is made easy to swallow by the idea that your code, for your tool or library or whatever else, can be just as powerful as a built-in bit of code.

Elm's maintaners decided to break this. They created what amounts to a caste system for code. If your code was blessed, then it got all sorts of extra abilities not granted to un-blessed code. And the sole authority on blessing was the cadre of developers.

Now, as to why they did this is a different discussion. There are good and bad arguments on both side. But as to why it comes up all the time? Ego

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

#73

Post by abrookewood »

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…

Sorry, but what is FFI???

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

#74

Post by josephcsible »

abrookewood wrote: post #73
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…

Sorry, but what is FFI???

Foreign function interface

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

#75

Post by cdelsolar »

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.

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

#76

Post by matsemann »

baobabKoodaa wrote: post #60
matsemann wrote: post #48

Earlier quoted context omitted.

I don't blame a Rust-codebase for being bad just because I don't know Rust.

So, your positive anecdote was somehow valuable for the discussion, but my negative anecdote had absolutely no value? That's how anecdotes work?

My positive anecdote proved that Elm is usable in production, which was the FUD I was refuting. Yours were irrelevant in that context.

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

#77

Post by matsemann »

paradox460 wrote: post #72
matsemann wrote: post #50

Earlier quoted context omitted.

I'm quite curious what Elm triggers so in people, that they years later actively hunts down discussions about it to interject their negativity.

They damaged the illusion of the "B" in "BDFL" with their changes in 19. Open-Source programmers like to believe that their toolchains and whatnot are egalitarian, and treat everyone as equals. Many accept the idea that the STDlib will be "more special," because its included in every copy of the language. This pill is made easy to swallow by the idea that your code, for your tool or library or whatever else, can be j…

That might be, but doesn't answer the question. There's plenty of tech I don't enjoy, still I don't interject myself into every discussion about those to bring it up.

It's like this meme. https://imgur.com/a/mjsMOGJ why do so many want to be the person to the left when it comes to elm? And so many years later?

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

#79

Post by vsuperpower2020 »

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

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

#80

Post by fulafel »

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…

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