The conversation

Lessons learnedExperience excerpt · English

In the half a dozen engineering orgs I have worked, each and every one became a quagmire of slow …

… In the half a dozen engineering orgs I have worked, each and every one became a quagmire of slow eng velocity and saw increased velocity and less bugs as they reduced context needed by teams. Separation of concerns, allowing individual services that run independently, more and better tests and observability, and, yes, better typing. Lots buy into the view "the old system got us here and now we can afford to rewrite and do things 'right'." The real cost is, literally, moths to years of dev efforts to unwind tangled concerns. Million to tens of millions in developer salaries that are going towards keeping the ship afloat as the hull is changed out. The opportunity cost is truly mind blowing. To avoid that cost: keep concerns separate, define data domains, and use a language that allows you to keep logic localized. If you have to jump files to understand your incoming parameters, you're gonna have a bad time when things no longer fit in your head, and esp. when new to the code as a new hire. …

Original discussionElixir v1.20 released: now a gradually typed language411 source comments · at import
2

What was this responding to?

Parent context · original excerpt

AB

Honestly, I think you're framing this incorrectly. Twitter, Airbnd and Shopify all managed to get massive using Ruby on Rails. Maybe that was part of the reason why? I.e. they were able to move fast and developers were happy. I don't use Rails, so don't have any skin in the game. But who cares if you have to do a re-write once you get to that size?

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 2

Direct replies available in this import. Original-language excerpts.

KE

> Elixir, I still had to know my whole call chain to know what I could do with my incoming parameters. The more call sites, the more mental context. but the call chain doesn't have to be long, i.e. it could be just 2 or 3 places; that fits inside my head. less is more

Full original
GL

There is almost nobody in startup world that will put the failure of a product/startup to choosing a dynamic language. Probably there are some exceptions where it matters but very few to count and in those cases yes use the most performant strongly typed, with string tools for static analysis and performance optimisations. The real truth is that language preference (typed or dynamic) are more of a fashion choice in most companies where I was present than a pure technical consideration. if you build your product by accumulating technical debt without any focus and effort toward simplicity and trying to make it do anything then the solution after many years is rewriting. But if you have the same culture and keep the same customers you will be in the sample place where you have started but now having different category of problems (eg network latency vs N+1s). Maybe this is the "way of the …

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.