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

91–100 of 180 posts

Re: Elm at Rakuten

#91

Post by aeturnum »

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…

I'm not an Elm veteran like a lot of the folks here, but I think an aspect of Elm is that a lot of the traditional ways that people expand ecosystems are discouraged by Elm's approach. For instance, components are hard to do in Elm and are discouraged in the documentation[1].

So my own personal Elm projects have involved a lot of reading other code and often copying and modifying open source code, but it's hard to wholesale import components in the way that JavaScript and other languages do it. My experience with the language is that it is very easy to do what I want in it, but it seems more difficult to share that as an open source contribution in Elm than in similar languages.

[1] https://guide.elm-lang.org/webapps/structure.html

Re: Elm at Rakuten

#92

Post by dimitrios1 »

ModernMech wrote: post #65
dimitrios1 wrote: post #53

Earlier quoted context omitted.

Once you detach from "I must use a library for every thing" land, you begin to realize you don't need the overwhelming majority of them. Which results in writing cleaner, simpler, more focused code, with less of a surface area for bugs. It's a whole mindset, tbh.

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.

except for the last one, all of those should be part of the language you are using, and well thought out + researched. I guess I should have been more specific: third party dependencies.

Re: Elm at Rakuten

#93

Post by gaereth »

rtfeldman wrote: post #41
cultofmetatron wrote: post #37

Earlier quoted context omitted.

Interesting food for thought. I bought your book awhile back and was 2 chapters in before reading about the aforementioned "Dissent is silenced and banned" issues which led me to abandon continuing at the time. Maybe I'll jump back into it. I've not heard of such misinformation being spread about other languages. Id love to hear your side on why Elm itself seems to attract such ire if its inaccurate.

It's a great question! I think there's more than one factor, but the biggest one comes down to setting expectations, especially in the early days. Elm does a lot of things differently than other languages, and while I think that overall those differences have been instrumental to its success, especially early on it sometimes wasn't clearly enough communicated when "this is temporarily different because it's a WIP; yo…

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

Re: Elm at Rakuten

#94

Post by mjaniczek »

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…

> Elm is fun, but I wouldn’t use it unless I could afford to hire a relatively huge team to absorb all of the additional complexity and detours that go into building an Elm app. There’s a constant promise of Elm being faster and easier to write for various reasons, but in practice it always seems to get bogged down in endless gotchas and framework shortcomings that need to be addressed before we can get down to getting real work done.

Is this your experience writing Elm apps in production? I am writing large Elm apps in production and I'm having very different experience to what you just described.

Re: Elm at Rakuten

#95

Post by earth_walker »

decafbad wrote: post #80

mkose@casper:~/Desktop$ ./elm repl ---- Elm 0.19.1 ----------------------------------------- > Basics.modBy 0 3 Error: Cannot perform mod 0. Division by zero error.

This is correct behaviour, depending on the definition of mod. See, for example:

https://math.stackexchange.com/questions/516251/why-is-n-mod...

Re: Elm at Rakuten

#96

Post by kingaillas »

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

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 for various reasons. It can happen there is just a lengthy IT process to go through... eventually most reasonable requests will be filled (copied/mirrored internally, or binaries imported). But there is a delay.

This is all besides the point other than to say: I either need to wait a few weeks, or write my own minimal JSON library.

How hard can that be? I mean, it's just JSON. Well earlier today I was checking reddit and saw an announcement that "JSON for Modern C++ was released" (https://www.reddit.com/r/cpp/comments/p69plb/json_for_modern...). Hey cool, I can see what the library looks like and maybe rip off some of their code while I'm waiting for a "please mirror this internally" request to finish.

This library is thousands of lines long... for JSON. I'm not disparaging the author or JSON, it looks like an awesome library with great diagnostics, I'm more trying to point out that even for the SIMPLE format of JSON, a serious library is 10K+ lines. That's a hell of a lot of extra work to put on a team when writing a JSON (or whatever) library probably isn't the actual work that needs to be done.

Elm likely has a JSON library ready to use, but having your seasoned team reinventing the wheel for so many other libraries isn't a good use of dev time. I can't think of simpler libraries to write than JSON and even that is 10K lines long. Other than the insanity of nodejs and leftpad and libraries like that. If the attitude for every single library needed is "we can write that from scratch" the team is never going to get anywhere.

Re: Elm at Rakuten

#97

Post by scotttrinh »

dimitrios1 wrote: post #92
ModernMech wrote: post #65

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

except for the last one, all of those should be part of the language you are using, and well thought out + researched. I guess I should have been more specific: third party dependencies.

In this specific case (Elm vs. JavaScript) We're talking about JavaScript here, so:

> - ubiquitous things, like data structures

There are a few basic data structures in JS, but almost everything else is in user-land.

> - hard to get right things, like time

Date is a notoriously bad API in JavaScript.

- implementations of specs, like Unicode

We just get a String type in JavaScript which is UTF-16, so...

Re: Elm at Rakuten

#98

Post by G4BB3R »

GiorgioG wrote: post #43

The bus factor of 1 makes it a non-starter for me for any serious project.

I could use Elm as it is today for at least a decade without updates, since it's very stable. Anyway, I am sure there are very competent people from the core devs or from the community that could make a new leadership if that happened.

Re: Elm at Rakuten

#99

Post by wk_end »

theobeers wrote: post #19
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…

From the opening section of the blog post, I wondered why an incremental move to TypeScript wouldn’t have worked for them. The rest seems to be all about Elm (I haven’t read it thoroughly), but I feel there’s a disconnect between the problem they started with and their choice to dive into a wholly new ecosystem. edit: Ah, hold on; I just got to where they comment on this. “TypeScript, which adds optional static typin…

To play Devil's (Elm's?) Advocate here: sometimes I wonder if the TypeScript promise of incrementally adding types to an existing JS code base is wishful thinking.

I'm at a company that's transitioning to TypeScript, and the reality is that you can't just flip a switch and have a well-typed codebase: if we just turn `strict` on, `tsc` gives us thousands and thousands of errors. And as we've gone through trying to annotate things, it's clear that in order to get various components to a state where they're properly type-safe, we'll need to almost completely rewrite them.

Compared to Rakuten, our codebase isn't even that huge or legacy - it's often very poorly written, but it's less than 50K lines and less than a couple of years old. No doubt the situation for Rakuten would be even worse; I'm sure huge swaths of their code would need to be trashed anyway.

If TypeScript is ultimately going to force you to rewrite - and still leave you with a less-robust solution - I could see why starting with a clean-slate with Elm would be appealing.

Re: Elm at Rakuten

#100

Post by WJW »

aszen wrote: post #66
mwcampbell wrote: post #61

Earlier quoted context omitted.

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

In a more mainstream language, while it may have a few Stripe client libraries but if your true use case of being real time isn't full filled then it makes no sense to choose them. A working stripe client takes at most a day to write, compared to years that can go in changing the architecture of your application

If you have enough talent that a good quality Stripe integration takes only a day to write, bending Rails or Laravel to serve websockets is not going to take more than a few days to write either. The true pain of non-standard languages is not in having to implement any specific dependency yourself but in having to reimplement a few dozen trivial-but-not-easy things yourself. It's a death by a hundred small cuts.
Post reply on HN