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

41–50 of 180 posts

Re: Elm at Rakuten

#41

Post by rtfeldman »

cultofmetatron wrote: post #37
rtfeldman wrote: post #31

Earlier quoted context omitted.

This is an example of the type of post I was referring to being tired of correcting. I don't use Reddit anymore, but if memory serves there have been about 5 people total banned from the aforementioned Elm subreddit, which is fewer than 1 ban per year it's existed. I invite anyone to evalute the accuracy of "Dissent is silenced and banned" with that data point in mind, and to evaluate the accuracy of the other above…

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; you can expect it to be more like what you're used to in the future" versus "this is different by design, so expect it to stay different or even to become more different."

Examples of this include typeclasses (a lot of people coming to Elm from a Haskell background assumed Elm would add them as a matter of course), JS interop (by design, it's not a traditional FFI, although there was an unintended backdoor that kind of worked like one; when that backdoor was finally removed, after much communication that in retrospect should have happened at the outset, some of those who had been relying on it were understandably upset), how the project is run (more like Clojure than like JavaScript), and what the release schedule looks like (batching large projects rather than more frequent smaller releases).

I think things are a lot clearer today, but for some it's unfortunately too late to make a difference.

Re: Elm at Rakuten

#42

Post by StefanWestfal »

From a self taught view, the compiler helped me a lot and when it compiles it usually works and when not the community is very helpful. Over all I found libraries usually of good quality while also not needing a lot as Elm includes a lot out of the box (i.e. React, Redux, axios, type guards, etc.).

Elm-UI made working with styling much easier for me and was the main reason I gave Elm a try.

The Evan and the core team seem to have a clear vision of what they want and I can understand that but this is personal opinion. To make a system work well you have to be strict and including new features all the time might introduce complexity down the line. This might seem a bit closed in form the outside.

So far I am very happy with it.

Re: Elm at Rakuten

#44

Post by dsiegel2275 »

It is refreshing once again to see an Elm post that looks at the pros and cons of the language and ecosystem, instead of solely focusing on a perceived problem with the way that the community is run.

Re: Elm at Rakuten

#45

Post by rtfeldman »

zoul wrote: post #40
rtfeldman wrote: post #31

Earlier quoted context omitted.

This is an example of the type of post I was referring to being tired of correcting. I don't use Reddit anymore, but if memory serves there have been about 5 people total banned from the aforementioned Elm subreddit, which is fewer than 1 ban per year it's existed. I invite anyone to evalute the accuracy of "Dissent is silenced and banned" with that data point in mind, and to evaluate the accuracy of the other above…

FWIW, I have the same experience as the parent poster. I used to love Elm, evangelized the architecture, wanted to write Elm professionally. I was constantly bumping into things that were not finished or working, but didn’t really mind. But I also often encountered cases where the leadership team was saying “we don’t want this discussion here, thank you very much”, even if the discussion was perfectly legitimate, fri…

Totally fair! I'm sorry to hear you had that experience, although I hope maybe you'll someday consider giving it another chance in the future. :)

My personal experience has been different, but I upvoted this because I really appreciated that you shared your own experience without overgeneralizing it.

Re: Elm at Rakuten

#46

Post by agbell »

For those want to learn Elm, or to learn strongly typed functional programming in very well thought out order @rtfeldman's book "Elm In Action" is super good.

His experience working at a teaching company made his book very well structured for new comers.

Re: Elm at Rakuten

#47

Post by Silhouette »

pjlegato wrote: post #30
dimitrios1 wrote: post #12

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

Quality engineering must always be balanced against the reality of finite budgets. Sure, lots of amazing engineering can be achieved in theory, _given infinite funding_. That never happens in the real world. One always has limited time to produce a viable product. There is always some extrinsic constraint to how much time can be spent taking your time and understanding what you're doing. Moreover, if you are operatin…

This is the popular wisdom but I question how universally applicable it is. We all know that having the best technology doesn't necessarily mean you win in a commercial market and we all know that being first mover can be an advantage, but those observations don't tell us what will be successful in the long term.

How often does substandard technology and technical debt become a drag on a business not long after that first move, allowing someone else to overtake because the poorly built system couldn't scale to production levels or wasn't adaptable enough for changing requirements or failed so often that the early users drifted away? How often do we see developers advocating shortcuts and showing limited understanding of basic software development or computer science ideas, only to see the product they work on being rewritten within a year or two, or the whole team shut down?

You can try to be fastest always. You can often succeed, at first, if you take enough shortcuts. But you can't sustain that pace without enough quality in your people and your code. Planning to throw each implementation away and rewrite with more resources every year or two is a very unicorn-like strategy. It reminds me of VCs whose strategy is to invest liberally, who are fully aware that most of those investments won't work out but they're hoping for one or two in each batch to become the next big hits.

Real engineering isn't done in a vacuum and its goal isn't perfection. Real engineering takes issues like costs and timescales and staffing into account and aims to find a solution that is good enough on all counts. But it still has to be good enough. Producing junk but quickly and cheaply is an effective strategy until it's not and the success of any product using that strategy comes down to little more than the luck of the draw.

Re: Elm at Rakuten

#48

Post by jeofken »

macintux wrote: post #24
jeofken wrote: post #16

Earlier quoted context omitted.

Would it not be to prevent supply chain attacks, and to guarantee the user that all code you run is pure and type safe? They don’t hinder anyone from forking and removing this limitation, allowing any package author to run native code on your machine.

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

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