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

51–60 of 180 posts

Re: Elm at Rakuten

#51

Post by macintux »

jeofken wrote: post #48
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).

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.

Re: Elm at Rakuten

#52

Post by Silhouette »

PragmaticPulp wrote: post #32
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…

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

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.

That's true but the vast majority of what you find on NPM is not mainstream, battle-tested libraries.

Libraries that do clear that bar tend to be widely useful but that suggests generality you won't necessarily need for any single use case. A couple of good engineers might struggle to beat a well-established open source library at everything it does, but that is rarely what they are trying to achieve. They just need something that is better for their own specific needs at that time, which might be a useful and realistic target.

Re: Elm at Rakuten

#53

Post by dimitrios1 »

PragmaticPulp wrote: post #32
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…

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

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.

Re: Elm at Rakuten

#54

Post by 0xFACEFEED »

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…

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

While this is obviously true, I don't think it depicts the actual decision making process that leads to messy codebases and crappy products. In my experience lack of experience and/or laziness play a big part.

A competent tech lead that's passionate about quality AND is willing to be annoying for the greater good makes an enormous difference. I'm talking multiple orders of magnitude difference.

It's the difference between spinning up a k8s cluster + service mesh vs tiny single server vps with basic failover. The former is thousands of hours of dev time across multiple disciplines while the latter a seasoned engineer can handle by themselves.

Re: Elm at Rakuten

#55

Post by pjlegato »

Silhouette wrote: post #47
pjlegato wrote: post #30

Earlier quoted context omitted.

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…

I totally agree. Engineering should be the best it can be, within the constraints of the resources available.

My post was addressing the common case where an engineer seems to ignore the 'resource constraints' side of the equation altogether.

Balancing these factors is more art than science. No two projects have the same set of resource constraints, nor the same set of engineering challenges. Luck is a big factor. The solution depends heavily on the exact details of each particular case.

Re: Elm at Rakuten

#57

Post by k__ »

PragmaticPulp wrote: post #32
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…

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

But...!

I've also seen many developers for years adopting mainstream libraries and frameworks wrongly.

The atrocities I've seen built with Ember, Rails, Angular, and the like.

Often these people built their own (albeit less powerful) libraries and could work much better with them.

Re: Elm at Rakuten

#58

Post by PragmaticPulp »

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…

> Your company usually goes bankrupt, and all the engineers will complain at their next jobs about what a wonderfully designed engineering system they were building, and how awful it is that nobody appreciates such things these days.

This is precisely why I try to interview tech leads about what they shipped rather than what they built. There are a lot of otherwise very talented developers out there who will spend years playing around in your codebase, writing beautiful code, but not actually shipping anything useful. Replacing them with shipping-focused engineers, even if they're not as technically competent, usually results in big productivity boosts.

This isn't a popular opinion among developer communities, but it's a common theme in the management forums I'm part of. It's important to have fun and budget some time for things like open-source contributions and library building, but the top priority must always be on shipping product.

Re: Elm at Rakuten

#59

Post by Silhouette »

aranchelk wrote: post #22
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…

> This is the biggest downfall of Elm projects that I’ve seen in the real world. Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online. This is an important point; I think it applies to varying degrees to any less popular language or framework. It’s a little worse with Elm because of the restri…

I'll add that unless you're very familiar with the framework/language you'll be using, it's pretty hard to estimate scope of work

I think you've just defined a pretty good benchmark for when it's sensible to consider a less popular choice. Are you familiar enough with it to be confident of coming out ahead by using it? Perhaps you have a backup plan like the interop you mentioned if some functionality is missing. Perhaps the tool is so much more productive in general that you are reasonably confident any extra development work to fill in the gaps will be outweighed by the overall benefits. But there should be some clear reason you think the risk is justified.

Re: Elm at Rakuten

#60

Post by platz »

aranchelk wrote: post #22
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…

> This is the biggest downfall of Elm projects that I’ve seen in the real world. Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online. This is an important point; I think it applies to varying degrees to any less popular language or framework. It’s a little worse with Elm because of the restri…

curious if you using halogen or react-basic? I've gone with halogen for a small project and it's been fine but sometimes i wonder if react-basic is a better choice.
Post reply on HN