What are Elm users using on the back end? FP or mainstream languages?
Any back end stack that can provide APIs, we're using .NET.
Elm at Rakuten
141–150 of 180 posts
Re: Elm at Rakuten
#142Earlier quoted context omitted.
This is correct behaviour, depending on the definition of mod. See, for example: https://math.stackexchange.com/questions/516251/why-is-n-mod...
The promise was no runtime errors .
My team is working on a very large Elm codebase for over 3 years now, we got a runtime error in production only once (stack overflow when parsing an unusually large file, made it tail call optimized to get rid of it).
I will consider it sticking to it's promise of no runtime errors.
Re: Elm at Rakuten
#143The bus factor of 1 makes it a non-starter for me for any serious project.
even the docs are written in first person
Re: Elm at Rakuten
#144Earlier 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…
> 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. It's not that simple. I realize this may be uncommon, but it's possible to work on a product that is truly worthwhile, that improves peoples' lives, and whose target users urgently need a solution to the problem you're s…
I've worked on, and am working on projects that are dying because the libraries that were added are now out of date.
It gets really hard to maintain after 10 - 15 years. I wish we had rolled our own libraries for some of the simpler functions. Even in PHP this would have made life so much better.
Re: Elm at Rakuten
#145Earlier quoted context omitted.
> 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…
This is a common argument i have seen devs make when evaluating building from scratch vs adoption, here's what building from scratch gives you, a leaner more understandable piece of code that does what you want and nothing more. An open source library is necessarily generic and has to be battle tested to make sure it fulfills all use cases, while the library you write only has to cover your own needs that makes it ea…
Not to mention when the language you are using updates and you have to update the code. If the 3rd party library is no longer maintained you have to upgrade the library yourself.
It's much nicer if it's a small bit of code you wrote with only the use cases you need.
Re: Elm at Rakuten
#146Elm 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…
F# solves many of these problems with it's ability to pull in C# libraries. When looking for a functional language to learn I settled on F# and am loving it so far. I'm not sure if I'd ever use it in production as it is still very niche.
What Evan is doing with Elm is awesome, he has a small closed set of features to make a language that is aimed at doing one thing. He has very tight control to make sure there is zero cruft in the language. It's an amazing project. The cost is that it's very hard for outsiders to have any input into the language. So the ecosystem will never take off.
Re: Elm at Rakuten
#147Earlier 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…
Geniune question: Can you name any complex software that is written in pure functions?
This is not a "discussion" question, but a "fill my blind spot" question.
I always read how good FP is, and how much better it handles all the complexity. Yet I never see it win from software written with state.
Is there any big and/or complex sofware written in FP that I am overlooking?
Re: Elm at Rakuten
#148Earlier quoted context omitted.
Nah it's a pretty good representation. And acting like time should 100% be spent writing features is shortsighted - sometimes it's worth it to pay fixed costs such as filling in a gap of the ecosystem of the language you chose for higher reasons than cranking out business code.
What's this higher reason? Isn't the point to crank out business code?
"Crank out" was supposed to imply optimizing the short-term. Ensuring your next sprint has the most output as possible.
If you choose an FP language like Haskell, you tend to value things beyond that. Stability, engineering culture, retention, big rate, the ability to extend things for cheap only because you did the hard part of using Haskell to begin with, etc
It's just throughput vs latency
Re: Elm at Rakuten
#149Earlier 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…
Geniune question: Can you name any complex software that is written in pure functions? This is not a "discussion" question, but a "fill my blind spot" question. I always read how good FP is, and how much better it handles all the complexity. Yet I never see it win from software written with state. Is there any big and/or complex sofware written in FP that I am overlooking?
Various classical optimization problems are just pure functions. The sorts of things used all over the place in industry (supply chain ops for instance)
If you want real production software, Starbucks Rewards is/was powered entirely by pure Haskell code and made big bucks
Software having complex state actually makes Haskell even better than the competition. Because most state has nuanced rules about its state transitions.
Haskell definitely has more of a learning curve when it comes to dealing with state, but that curve will guide you towards a ceiling mainstream languages can't even approximate.
Re: Elm at Rakuten
#150Earlier 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…
I don't think it's merely small librarys. Last I checked localization in Elm was a pain, and I'm sure there are numerous other features missing.
Elm's library ecosystem is a bit iffy in my experience compared to Haskell or Scala. Those two don't really have huge gaps nowadays, and they're buoyed by better FFI (Haskell w/C, Scala w/Java) than Elm's draconian JS interop.