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

151–160 of 180 posts

Re: Elm at Rakuten

#151

Post by slgeorge »

hashbig wrote: post #126
G4BB3R wrote: post #102

Earlier quoted context omitted.

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.

And who can contribute to `elm` and `elm-explorations`? The 7 cool dudes. The Elm contributor circle is a clique that you literally have to be a strong contact with one of the contributors to get into it. It goes against everything open source stands for.

> It goes against everything open source stands for

Sorry, that's not correct. It goes against your opinion of what open source should stands for, and many projects run in a way where everyone can contribute. But, it's not the only way.

The license determines how the code comes, that's the only rule. There's no rules about how a community must run. It's for the code creator (maintainer) to determine how or even IF they want a community of contributors. There's lots of ways of doing open source!

And saying it's not "open source' if you don't do X outside the license is just a No true Scotsman.

Re: Elm at Rakuten

#152

Post by gaereth »

G4BB3R wrote: post #102
gaereth wrote: post #93

Earlier 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 thing I found unsettling wasn’t that something was disabled (fair design decission), but the mindset that considers some features harmful , but is happy enough to use it in its own „special case projects/packages”. It doesn’t really matter for how many packages its available, since it can be changed on a whim. I can only speak for myself, but I found it unfair and patronizing

Re: Elm at Rakuten

#153

Post by jeofken »

macintux wrote: post #51
jeofken wrote: post #48

Earlier quoted context omitted.

Who cares? It’s a computer program, just have it do what purpose you require

Forking has long-term maintenance costs, even without the hassle of trying to hide your efforts from the Elm maintainers. I’d be fine forking it to pursue a personal project. I’d never do that for any critical business need.

• Your company has a patch allowing installing binary code from other sources

• When you want to update to a new version of Elm, do git rebase and reapply the patch.

• Now your source tree and history is identical to upstream, plus one commit

Most likely the code restricting installing binaries from only one source isn’t changing a lot, so patch conflicts should not be too much of a hinderance

Re: Elm at Rakuten

#154

Post by jeofken »

vmchale wrote: post #38
macintux wrote: post #24

Earlier quoted context omitted.

> They don’t hinder anyone from forking and removing this limitation, allowing any package author to run native code on your machine. That has arisen a few times here. Yes, they actually do actively discourage forking (to the point of threatening “excommunication” from the community).

Yeah if anything the need to constantly fork the compiler indicates a problem lol.

It can be as simple as having a patch and just updating by reapplying the patch over the master branch. You’d have to build from source of course, rather than downloading someone else’s binaries.

Re: Elm at Rakuten

#155

Post by aszen »

WJW wrote: post #100
aszen wrote: post #66

Earlier quoted context omitted.

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.

On the one hand u r writing a wrapper over an already well specified rest api of stripe and on the other hand u need to modify a programming language runtime to be faster and reliable for real time operations. I'm not sure these tasks are really comparable in any way.

Choosing non-popular languages is a trade off yes but not as much as people think especially if you have a good team willing to learn them.

There are also benefits apart from technical ones like better job retention and attracting finer talent without having to filter hundreds of resumes. I will say if your business is made around hiring and making anyone work of the shelf then it's a bad idea.

Re: Elm at Rakuten

#156

Post by wolfadex »

dzonga wrote: post #134

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

I had the opposite experience with my last job interview. I didn't know any Ember but I did know Elm (and other languages and frameworks). My enthusiasm about Elm absolutely contributed to my being hired and my lack of Ember knowledge didn't hurt me. This was what the hiring manager told me.

Re: Elm at Rakuten

#157

Post by gen220 »

koonsolo wrote: post #147
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…

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?

Many banks and hedge funds are semi famously using FP (whether that’s OCaml, Haskell, or Scala). JP Morgan has a big Haskell corner. Jane St is the company I most associate with with OCaml. Jet.com is largely built with F#.

In business domains with strict audit requirements, it’s a peace of mind thing, to know that “side effects” (aka persistence and the mutation of persisted data) are constrained to a tiny and highly testable corner of your code base.

For OSS, the examples that spring to mind for me are RabbitMQ (Erlang) and Pandoc (Haskell).

Re: Elm at Rakuten

#158

Post by dimitrios1 »

scotttrinh wrote: post #97
dimitrios1 wrote: post #92

Earlier quoted context omitted.

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

> We're talking about JavaScript here, so:

Well, no, we aren't. We are talking about the Elm language, which compiles to JavaScript.

There are also other excellent languages that target JavaScript that have these things.

Re: Elm at Rakuten

#159

Post by mchusma »

Rakuten is basically a scam on merchants right?

By that I means they use affiliate links to make money.

But most of their referred traffic comes from people checking out and saying "I use rakuten to get a discount at the places I already shop".

The stores then don't know how much business rakuten is really bringing them, so are scared to stop it.

Consumers keep checking rakuten to see if they get discounts on things they want, because why not?

Is this a good summary? Anyone have a more favorable impression of their work (from the store perspective)?

Re: Elm at Rakuten

#160

Post by razze »

adamwk wrote: post #130
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…

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.

Check https://package.elm-lang.org/packages/ChristophP/elm-i18next...
Post reply on HN