What are Elm users using on the back end? FP or mainstream languages?
we are using rust on the backend
Elm at Rakuten
131–140 of 180 posts
Re: Elm at Rakuten
#132Earlier quoted context omitted.
I appreciate libraries for: - ubiquitous things, like data structures - hard to get right things, like time - implementations of specs, like Unicode - hardware interfaces, like CUDA For everything else, I'll take the above and roll my own solution.
What about something tedious and ubiquitous, such as swapping between camel and snake case?
This is exactly the case where you don't need a library. This is a single function (or two) and you can easily translate an existing code example into the language you're using in a few minutes and be done with it.
Re: Elm at Rakuten
#133Earlier quoted context omitted.
I have heard otherwise, both in comments here and via https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#forka... , but it’s entirely possible I’m wrong. Added: This comment is also not terribly friendly. https://github.com/gdotdesign/elm-github-install/issues/62#i...
My word choice certainly could have been better (I was upset, and it showed), but to quote what I said there anyway: "If you understand the design goals, but don't agree with them, why not channel that in a positive way - e.g. by building something that fits your vision instead of directly working against Elm's design goals?" - in substance, this is consistent with what I said above: it's totally encouraged if anyone…
I'm glad things turned out well. I definitely am hoping Elm can help me bootstrap into the more formal FP world.
Re: Elm at Rakuten
#134little anecdote: I did a couple of personal projects in elm in 2017. one thing I'm thankful for it taught me functional programming. Elm was easy to start with for someone new to functional programming. it also taught me, one important lesson - the market doesn't really care. a company when you're looking for a gig doesn't care if you know elm, it wants you to know the 'framework'they're using currently. so yeah, I see elm being a dead end. either people using it already solved product/market fit. but for a startup getting off the ground - elm offers no benefits at all compared to js.
Re: Elm at Rakuten
#135What are Elm users using on the back end? FP or mainstream languages?
We're using Elixir on the backend at Corvus Insurance and it's quite nice.
Re: Elm at Rakuten
#136Earlier 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 .
There are two that I can think of: this, and the fact that there's no equality class yet. In practice it just doesn't come up.
Re: Elm at Rakuten
#137Earlier quoted context omitted.
One thing is that it wasn’t communicated that well, but other (and that’s what made me feel really uncomfortable) is that it felt like „This feature is not allowed anymore - except for some dudes, they’re cool enough and can use it” (e.g. native modules, operators). Either keep or drop feature
Kernel code and custom operators are only allowed under elm/ and elm-explorations/, so only 7 core packages can use them. The core developers cannot use those features in projects like everyone else.
The problem is there are some reasonable features that cannot be implemented with the current ports system that _should_ fit into the expected design. Specifically, I feel you should be able to replicate the `Http` module using ports or some other available system. However, you cannot properly dispatch a task and then tie together the result with a curried `Msg`, as you might expect or hope [unless you store a complex state object in your model]. These types of issues are the frustrations that, I believe, cause some discontent in the community. I feel more people understand why you should not, per se, make random FFI calls in the middle of pure code (e.g. since it would break dead code elimination and require evaluation order guarantees), but other restrictions seem arbitrary.
Re: Elm at Rakuten
#138Earlier 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…
Speaking as someone who liked Elm for a while, then abandoned it, I will say that the biggest problem with the language is absolutely its leadership. Development moves at an absolutely glacial pace and basically takes place with no transparency at all. I would argue that it's more like a "source available" project than an "open source" one since the core dev team is so exclusionary. Most planning takes place inside E…
[deleted]
Re: Elm at Rakuten
#139The part of the article that I was waiting for was how they got it adopted in Japan. Having worked in Japan for almost a decade I can easily say it is not an easy feat to change Japanese corporate mindset when it comes to a programming language or environment. I wonder what the elevator sales pitch was. Other than that I think this was a great article.
Re: Elm at Rakuten
#140"the order in which we write the code doesn’t matter"
What do you lose in this trade off?