Elixir at Ramp • Hacker News Board

Re: Elixir at Ramp

#41

Post by busterarm » Fri, Jun 04, 2021, 5:43 PM UTC

strzibny wrote: post #40

busterarm wrote: post #39

Earlier quoted context omitted.

My career specialty is deployment at the 10^5 scale and I'd argue that Python has no business on Production systems. Heck, I'm a former career Rubyist and I'd say the same there too. At a certain point statically linked binaries are going to make several classes of hard problems to solve disappear entirely and is IMO baseline criteria for operating at this level. BEAM at least has some compelling features working in…

> It's well-adapted for smaller scale systems. I wonder what they switch to at WhatsApp when they become medium scale.

Hey. I write Elixir & Erlang sometimes too. I'm an Erlang Ecosystem Foundation member.

There are very real and well-known scalability limits of Erlang clusters and applications that run in them. This isn't someone talking shit, but instead just operating within the limitations imposed by reality. Message passing has overhead -- it's not free.

WhatsApp probably doesn't need nearly as much hardware as you think.

Re: Elixir at Ramp

#42

Post by strokirk » Fri, Jun 04, 2021, 9:48 PM UTC

pmontra wrote: post #36

strokirk wrote: post #26

It annoys me how much Elixir zealots proselytize the language as the the objectively best thing since sliced bread, and all other languages are worse. But it's a well written article. Good on them for finding Elixir useful, but none of the benefits they talk about seem very compelling for me. Most of them are available as table stakes in other languages (rerunning failed tests as an USP of mix test, really?), or very…

The missing return statement has never been a big deal in my experience. In part it's absorbed by pattern matching (multiple definitions for the same function) and in part by "let it fail." Tracebacks are not so bad but they tend to be useless when the cause of an error is in a different process than the one that failed. I know that my GenServer failed at line x with data y, z but I don't know what sent that x to the…

IMO pattern matching often makes the code harder to read, especially with deep destructuring spanning multiple lines. Could be our codebase, but writing code prolog-style has always made it neigh-unreadable to me.

Re: Elixir at Ramp

#43

Post by joelbluminator » Tue, Jun 08, 2021, 5:38 PM UTC

busterarm wrote: post #39

nickjj wrote: post #24

The author wrote: > My hot take about most dynamic languages is that they are a poor fit for startups who have intentions of being long-term businesses I don't think that's fair to say. There's plenty of long term businesses running at scale using dynamic languages. That's employee and load scale too. Dropbox is ~13 years old, has ~4 million lines of Python and operate at crazy scale. I ended up talking to one of the…

My career specialty is deployment at the 10^5 scale and I'd argue that Python has no business on Production systems. Heck, I'm a former career Rubyist and I'd say the same there too. At a certain point statically linked binaries are going to make several classes of hard problems to solve disappear entirely and is IMO baseline criteria for operating at this level. BEAM at least has some compelling features working in…

> I'd argue that Python has no business on Production systems

Well yes you would argue, you did. That doesn't make your argument true or important.

Re: Elixir at Ramp

#44

Post by busterarm » Thu, Jun 10, 2021, 2:53 PM UTC

joelbluminator wrote: post #43

busterarm wrote: post #39

Earlier quoted context omitted.

My career specialty is deployment at the 10^5 scale and I'd argue that Python has no business on Production systems. Heck, I'm a former career Rubyist and I'd say the same there too. At a certain point statically linked binaries are going to make several classes of hard problems to solve disappear entirely and is IMO baseline criteria for operating at this level. BEAM at least has some compelling features working in…

> I'd argue that Python has no business on Production systems Well yes you would argue, you did. That doesn't make your argument true or important.

Sorry, but at this scale of systems and how often you're replacing hosts, it's absolutely critical that you always have a deployable. That's not provably true in the Python ecosystem (unless you're insane and vendoring all of your dependencies separately for every single application you deploy).

At the end of the day what you need is a statically linked binary. There are tools like cx_freeze and Nuitka that try and get you there but ultimately aren't worth the effort and give you other problems to solve as well. Or you could use cython, but again, more problems. You're simply better off using a language that reduces your (business) risks from the onset.

I'm sorry that that makes you feel bad, but that's facts and anyone working at this scale will tell you so. We pretty much only deal with Python where we have to (in the ML space). If a company is really stubborn about it though it's often better to just not take those jobs.