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

111–120 of 180 posts

Re: Elm at Rakuten

#111

Post by PragmaticPulp »

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…

> But yeah if you're a software efficiency bean counter, maybe you won't like FP. Fair point.

> My opinion is the long-term technical & cultural benefits and opportunities pay off.

How, though? These two points contradict each other. Is using FP going to pay off with technical benefits? Or is it just going to reduce your software development efficiency?

I enjoy writing FP code and using niche frameworks like Elm for hobby projects, but I specifically avoid them for production work because I'm familiar with them.

I always hear claims that using Elm and niche languages is going to pay off in vague benefits somewhere down the road, but in practice the payoff never really arrives. I think a lot of developers pushing these niche frameworks tend to mentally dismiss the actual costs and overhead incurred by using something like Elm.

It's tempting to categorize the struggles as "learning" and therefore try to pretend it doesn't count as lost time, but at the end of the day if your team has to spend extra cycles doing extra things just to accomplish basic tasks, it's a drag on productivity.

Re: Elm at Rakuten

#112

Post by whateveracct »

PragmaticPulp wrote: post #111
whateveracct wrote: post #72

Earlier quoted context omitted.

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…

> But yeah if you're a software efficiency bean counter, maybe you won't like FP. Fair point. > My opinion is the long-term technical & cultural benefits and opportunities pay off. How, though? These two points contradict each other. Is using FP going to pay off with technical benefits? Or is it just going to reduce your software development efficiency? I enjoy writing FP code and using niche frameworks like Elm for…

Everything you say is optimizing for the short-term. When it comes to total cost of development, I think FP wins out even if you have to fill ecosystem gaps.

But if you can't afford for ANY time to not be spent directly on the business, don't do FP. Sounds like a pretty brutal way to work.

FP has _throughput_ benefits, but may come with _latency_ hiccups while your team climbs the learning curve (which may include writing libraries.)

If you have frequent deadlines (or treat 2 week sprints as deadlines), then FP won't jive..and you probably have bigger pain points in your company than PL choice lol.

Re: Elm at Rakuten

#113

Post by whateveracct »

kingaillas wrote: post #96
whateveracct wrote: post #72

Earlier quoted context omitted.

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 I don't think it is. At work, I'm adding some basic metrics/logging functionality to an internal library, to see how it's being used. The idea is to log a few parameters and the tech lead suggested using JSON format. No problem right? Well my work environment is quirky and let's just say it is hard to use outside libraries…

A json serialization (no parsing) library is not going to be 10k+ lines, and it's going to be extremely simple.

You can define a JSON AST type very simply, and then converting that to wire bytes is also quite trivial. Also simple to test via golden testing (you could even use property testing + shell out to jq to validate the json)

https://github.com/nikita-volkov/jsonifier This one is nowhere near 10k lines - and it is heavily optimized and polished!

Re: Elm at Rakuten

#114

Post by MichaelGlass »

5350-uiop-1130 wrote: post #6

Wouldn't it be difficult to find other developers that are experienced using Elm? I don't know much about it tbh. Probably, one of my biggest career mistakes was opting for a little known PHP cms instead of WP as I thought it would be easier for the stakeholders to work with the limited options. Since then, I've always avoided going away from the mainstream toolset.

FWIW our experience has been: - finding devs with experience is hard - finding great devs who want to use interesting tooling is easy

In the end, we hire interesting, curious devs, and ask them to use tooling (elm) that has a pretty shallow learning curve.

I think bootstrapping a project in Elm without any experience on the team could be tough, but once you have some expertise, the seeds you plant in yield abundant fruit. At NoRedInk it's been a great success -- especially with regards to "finding other developers".

Re: Elm at Rakuten

#115

Post by PragmaticPulp »

whateveracct wrote: post #112
PragmaticPulp wrote: post #111

Earlier quoted context omitted.

> But yeah if you're a software efficiency bean counter, maybe you won't like FP. Fair point. > My opinion is the long-term technical & cultural benefits and opportunities pay off. How, though? These two points contradict each other. Is using FP going to pay off with technical benefits? Or is it just going to reduce your software development efficiency? I enjoy writing FP code and using niche frameworks like Elm for…

Everything you say is optimizing for the short-term. When it comes to total cost of development, I think FP wins out even if you have to fill ecosystem gaps. But if you can't afford for ANY time to not be spent directly on the business, don't do FP. Sounds like a pretty brutal way to work. FP has _throughput_ benefits, but may come with _latency_ hiccups while your team climbs the learning curve (which may include wr…

> When it comes to total cost of development, I think FP wins out even if you have to fill ecosystem gaps.

This is the core point I was disagreeing with:

In my experience (yes, I have used Elm and I enjoy various functional languages), this payoff never comes. There's always something more that needs attention, needs another developer, needs to be refactored because we forgot a use case, and so on.

And also in my experience, by the time you've invested the years of effort required to fill in gaps in the public package ecosystem, it's time to move on to the next niche language trend. I'd rather invest our time and energy in mainstream languages that have staying power, where we're not obligated to carry large parts of the open-source ecosystem by ourselves.

Re: Elm at Rakuten

#117

Post by whateveracct »

PragmaticPulp wrote: post #115
whateveracct wrote: post #112

Earlier quoted context omitted.

Everything you say is optimizing for the short-term. When it comes to total cost of development, I think FP wins out even if you have to fill ecosystem gaps. But if you can't afford for ANY time to not be spent directly on the business, don't do FP. Sounds like a pretty brutal way to work. FP has _throughput_ benefits, but may come with _latency_ hiccups while your team climbs the learning curve (which may include wr…

> When it comes to total cost of development, I think FP wins out even if you have to fill ecosystem gaps. This is the core point I was disagreeing with: In my experience (yes, I have used Elm and I enjoy various functional languages), this payoff never comes. There's always something more that needs attention, needs another developer, needs to be refactored because we forgot a use case, and so on. And also in my exp…

Years, plural?? Maybe Elm is just way less mature, but I was on a team that shipped Haskell software with millions of users in about a year of dev time..and this included huge investments in many missing libraries..all on top of using GHCJS which required investments to the toolchain itself (Elm is definitely more mature now than GHCJS was at the time.)

But that was Haskell I guess. It's obviously not a "niche language trend" by now, so it was pretty clear it had staying power.

Definitely has paid off for me personally. My side projects move a lot faster and more stably now that I cut my teeth in production Haskell. A real free 10xer to my skills personally. And I gained the skills by getting my employer to finance my learning lmao.

Re: Elm at Rakuten

#118

Post by dodecaphonic »

agumonkey wrote: post #68
osener wrote: post #56

Earlier quoted context omitted.

Do you have a link for this library?

I just spent 10 minutes digging google and I cannot find it again. I didn't even try to find about it last year, it seemed the only ui lib for purescript with a tiny docs website (beige / pale themed) Really surprised not being able to find it again.. I'll reply again if I end up finding it

Maybe you mean Concur? https://purescript-concur.github.io/purescript-concur-react/

Re: Elm at Rakuten

#119

Post by wolfadex »

fulafel wrote: post #116

What are Elm users using on the back end? FP or mainstream languages?

I have coworkers using Rails for the back end of their Elm app. I think NoRedInk is using some Rails and some Haskell. I've have a friend who uses Python for his back ends. Also heard that some people really like using F#, as well as Node.

Or if you want to do Elm full stack there's https://lamdera.com/ or https://package.elm-lang.org/packages/choonkeat/elm-fullstac....

Re: Elm at Rakuten

#120

Post by StefanWestfal »

ferdowsi wrote: post #85

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…

I had a similar line of thought in the beginning too. If you google Elm these issues pop up. However after some time posts about it lead back a very limited set of occasions and block posts. Which are either criticizing the leadership style or a few events. I view the leadership as a trade off which ensures a high level and guarantees for the core at the cost of a high barrier. For the fee events, I think we are all humans and make mistakes and usually it is a miss communication between two parts more then a real issue.
Post reply on HN