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

Elm at Rakuten

engineering.rakuten.today

Post reply on HN
Print view View original

81–90 of 180 posts

Re: Elm at Rakuten

#81

Post by jaeming »

rtfeldman wrote: post #17
jaeming wrote: post #13

Earlier quoted context omitted.

As I understand it, there was a rift in the community over the leadership's tone in messaging and communication. Some Developers also felt like they could not contribute in a meaningful way or have constructive discussion with maintainers. See posts like these for more details and comments: https://news.ycombinator.com/item?id=16510267 https://news.ycombinator.com/item?id=22821447 There are also several great alterna…

Honestly I think the main reason for this perception is that people in the Elm community have gotten increasingly tired of correcting inaccuracies people like to post about Elm on Hacker News. I spent a bunch of time doing that in the past, and eventually stopped because I felt like Sisyphus. The same people would crop up on the next thread repeating the same things anyway. Of course if the claims go unchallenged, it…

That's a good point and maybe I shouldn't have re-posted these stories in my comment as I have not personally witnessed this behavior. I just know that when I started learning Elm initially (Nice Frontend master courses btw) I ran into this sentiment a good bit on reddit and hackernews so thought there was probably something to it if it was being echoed by so many.

I'll add a reply to my comment to make it clear this is hearsay and doesn't necessarily reflect the truth.

Re: Elm at Rakuten

#82

Post by rtfeldman »

jaeming wrote: post #81
rtfeldman wrote: post #17

Earlier quoted context omitted.

Honestly I think the main reason for this perception is that people in the Elm community have gotten increasingly tired of correcting inaccuracies people like to post about Elm on Hacker News. I spent a bunch of time doing that in the past, and eventually stopped because I felt like Sisyphus. The same people would crop up on the next thread repeating the same things anyway. Of course if the claims go unchallenged, it…

That's a good point and maybe I shouldn't have re-posted these stories in my comment as I have not personally witnessed this behavior. I just know that when I started learning Elm initially (Nice Frontend master courses btw) I ran into this sentiment a good bit on reddit and hackernews so thought there was probably something to it if it was being echoed by so many. I'll add a reply to my comment to make it clear this…

Thank you, that's very considerate of you!

Re: Elm at Rakuten

#83

Post by jaeming »

jaeming wrote: post #13
folex wrote: post #5

Elm is awesome, its compiler is awesome, but its ecosystem is kinda stalling, isn't it? I mean, a lot of libraries aren't updated to the last lang version, debugging JS-Elm interactions been a real challenge for years, yadda yadda. Overall I'd say Elm ecosystem doesn't receive enough attention to survive. I'm not complaining, I'm just sad about that and kinda surprised I didn't found a mention of that in the OP artic…

As I understand it, there was a rift in the community over the leadership's tone in messaging and communication. Some Developers also felt like they could not contribute in a meaningful way or have constructive discussion with maintainers. See posts like these for more details and comments: https://news.ycombinator.com/item?id=16510267 https://news.ycombinator.com/item?id=22821447 There are also several great alterna…

After considering the way I phrased this comment above, I want to clarify that I never personally observed or witnessed this kind of behavior myself. My own dealings in the Elm community have been almost entirely positive. I had heard a lot of these criticisms from comments on hacker news or reddit and realize now they mostly resemble hearsay or people like myself repeating what they heard from others resulting in a sort of echo chamber. I apologize for adding to that echo chamber.

Re: Elm at Rakuten

#84

Post by Silhouette »

JamesSwift wrote: post #77
pjlegato wrote: post #55

Earlier quoted context omitted.

I totally agree. Engineering should be the best it can be, within the constraints of the resources available. My post was addressing the common case where an engineer seems to ignore the 'resource constraints' side of the equation altogether. Balancing these factors is more art than science. No two projects have the same set of resource constraints, nor the same set of engineering challenges. Luck is a big factor. Th…

See also: engineers who think that engineering considerations trump all other business considerations. You need to know when it makes holistic sense to rewrite, or ship a hack. There are a lot more people at the decision-making table than just engineering.

That is certainly true but somehow I suspect under-engineering is a more frequent problem in our industry than over-engineering.

IME retrospectives rarely sound like "We hired a team of strong developers, they did a solid job, but then the business failed as a result". The kind of developers who are strong enough to do a solid job are probably also experienced enough to recognise the other considerations in play and adapt if necessary.

Re: Elm at Rakuten

#85

Post by ferdowsi »

After the relevations about Elm's dysfunctional leadership culture[1] I have seen vocal discouragement about investing in Elm, and reasonably so. This is a culture where Elm's leaders actively attempt to shut down criticism as "emotional violence"[2], which is just incredibly immature hyperbole. I couldn't imagine investing the future of my job and workplace on an operation like this.

[1]https://news.ycombinator.com/item?id=22821447 [2] https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing...

Re: Elm at Rakuten

#86

Post by pkolaczk »

PragmaticPulp wrote: post #32
dimitrios1 wrote: post #12

Earlier quoted context omitted.

> but it’s not ideal if you’re trying to run a lean team that ships products quickly. Good. The longer I do this, the longer I realize that unless your in a race-to-the-bottom industry (something like vying for eye balls to increase ad spend), then this is categorically a bad thing. I would prefer the quality of engineering required in knowing how to do some of these things yourselves. Take your time. Understand what…

> I would prefer the quality of engineering required in knowing how to do some of these things yourselves. Realistically, a couple of engineers writing a library from scratch isn’t going to be higher quality than adopting a mainstream, battle-tested library that accomplishes the same thing. Writing your own implementations of everything can be fun, but it’s not possible to compete with all of the iterations and revie…

Often you don't need to reimplement 100% of functionality of a library but just a 1% of it. Then, a talented team can usually make that 1% higher quality just because they are not limited by the complexity and tradeoffs added by the remaining 99%.

Also many "battle-tested" libraries are not really very high quality - they all have bugs, unnecessary complexity and technical debt. Higher degree of testing they get is often offset by the higher number of feature requests, and more features means more complexity and more bugs.

And in reality I saw it many times when a niche library written by a solo developer is of a higher quality than a super popular behemoth written by hundreds of developers over 10 years.

Re: Elm at Rakuten

#87

Post by roebk »

The pros and cons listed hear mirror my own views of Elm. Although, we’ve only got a handful of small Elm apps in production it’s a joy to work on them. I can rip into them with a fairly big refactor, fix the compiler errors and be confident that it’s all going to work. I do which there were a larger selection of Elm packages to take advantage of, but integrating Web Components into Elm hasn’t been bothersome.

Re: Elm at Rakuten

#88

Post by fatnoah »

arcade79 wrote: post #35

I wonder if someone will create 'pine' - "pine is not elm". (For younglings: elm was an email client. pine was also an email client. The latter was often thought to be short for 'pine is not elm').

To be honest, I read the article and was expecting this to be about ditching Outlook or Gmail in favor of Elm.

Re: Elm at Rakuten

#89

Post by lhorie »

PragmaticPulp wrote: post #2

Interesting breakdown of some pros and cons of using Elm in production. However, it appears the JavaScript codebase they used for comparison was quite bad and maybe not representative of a good or even typical JavaScript app: > Our JavaScript application had global variables everywhere, and debugging was a nightmare Point #3 in their list of cons is especially important for anyone considering Elm: > Because Elm is no…

> Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online.

I dunno, having seen both sides, there are pros and cons to each.

Teams that reach for libs quickly often think in terms of libraries instead of solutions (one recent example was some folks who were asking for my advice on some over-engineered client-side PDF generation thing, and me suggesting `window.print()` as a solution, considering this was for an internal tool and you effectively want print stylesheets anyways), and often use them as crutches due to a self-fulfilling cycle of "I don't know how to do X, let's use a library so I never need to find out" (and then pulling in a huge lib to do the job of a literal one-liner regex - `uuid.validate()`, looking at you). In my experience, they also often end up buried by their own complexity due to gluing too many things together. But at the same time, it's hard to argue with the ease with which one can plop a modal dialog or a calendar or a collapsible table in a React app.

I find that teams working with more exotic technologies tend to be more creative with solutions (e.g. "oh there's no zoomable map UI lib bindings, so let's ask ourselves, do we really need a map library for that contact us page or is a static jpg good enough?") and a have a deeper appreciation for how hard things are to implement. But conversely, UX can suffer from too much "creativity". For example, if care is not taken w/ accessibility concerns for some UI element. Or, as you said, things just take longer to ship because people need to reinvent wheels.

Re: Elm at Rakuten

#90

Post by vlunkr »

whateveracct wrote: post #72
PragmaticPulp wrote: post #2

Interesting breakdown of some pros and cons of using Elm in production. However, it appears the JavaScript codebase they used for comparison was quite bad and maybe not representative of a good or even typical JavaScript app: > Our JavaScript application had global variables everywhere, and debugging was a nightmare Point #3 in their list of cons is especially important for anyone considering Elm: > Because Elm is no…

A seasoned small Elm team will probably scale to higher complexity heights than a small JS team in my experience. Same goes for Haskell and the like. The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here. Most of the time I see it, it's people flipping out at the very sight of there not being something available off-the-shelf. The actual cost is much lower than the panic impli…

> The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here

This isn't a good representation of the argument. People don't want to write libraries because it's more valuable for everyone to spend time writing features using existing libraries, provided there are good libraries available. People aren't "freaking out", they just have deadlines, and you know, other things to do with their lives besides write code that has already been written.

Post reply on HN