Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir at Ramp

engineering.ramp.com

Post reply on HN
Print view View original

31–40 of 44 posts

Re: Elixir at Ramp

#31

Post by danpalmer »

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 hot take about most dynamic languages is that they are a poor fit for startups who have intentions of being long-term businesses

The classic rebuttal to this is that the company needs the best chance of surviving today, and can fix it tomorrow.

There are problems with this approach, it's definitely harder to fix these problems later, but "at scale" is that really a problem? The big problem is getting to the scale, surviving long enough.

Re: Elixir at Ramp

#32

Post by papito »

halfmatthalfcat wrote: post #22
papito wrote: post #17

Earlier quoted context omitted.

The problem with Scala is that it's a huge language and it gives you a lot of ways to misbehave. It is the same exact problem that C++ has - too many people turn it into an intellectual exercise and a dick-measuring contest of who can write the most elegant (unreadable) code. If you ignore all that, Scala is an amazing language.

That's also a strength? If you (the technical founder) know how to leverage Scala and can hire competent Scala devs (there are a lot of them who exist), you can potentially cut your development team by some large factor.

That's all moot once you decide to do micro-services and your team has to explode by 10x, while completing the same work or less.

Re: Elixir at Ramp

#33

Post by hnedeotes »

chartpath wrote: post #27
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…

Hahaha maybe so, but have you met Go devs? The cult of "simplicity" and static typing fundamentalism is just a reaction to JavaScript IMHO. What these folks don't realize is that langs like Python can do everything including static types, and was always strongly typed, having never allowed bad casting edge cases like JS. I will also add that goroutines (and actors and other first-class concurrency constructs) built i…

Yeah, I mean, why would you want concurrency primitives when you can spawn a thread, or do mutexes, or do locks at the db level, or use redis as an actor, for when, for instance, you want to allow users to upload N simultaneous files, but have a limit by user plan to 5 maximum uploaded files, or process N CSVs or excel files in parallel and broadcast the changes to all admin accounts, or not allow multiple simultaneous edits to a resource. It's just more sane to rely on 3 or 4 moving pieces outside of your environment to achieve it.

In fact, I think you should go pitch this idea to all OSes developers, nobody is doing more than one thing at any given point in time, so clearly multitasking is unnecessary cruft, pthreads, selects, etc just cater to insecure devs that want to feel cooler and pretend they're not in the stone age of computing anymore.

Re: Elixir at Ramp

#34

Post by JeremyNT »

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…

I think it really does depend on the domain. When it comes to web, "move fast and break things" is the norm, and the expectation. This is exactly where dynamic languages are great - so what if you don't have the cleanest code, so what if you throw exceptions due to mismatched data types, if you can get the MVP out there then you're already half way there. Let future generations deal with the tech debt, using the warchest you amass from all the funding you can get by showing off your successful launch.

For lower level / systems programming, though, I think that's somewhat less true. Think about database plugins like timescale, or VPN solutions, etc - stuff that, if it breaks, somebody's having a really bad day. It's probably worth spending more time on robustness and then a statically typed compiled language can really help eliminate many classes of errors off the bat.

Re: Elixir at Ramp

#35

Post by losvedir »

jklm wrote: post #4
hggythhdtr wrote: post #3

Earlier quoted context omitted.

"My Elixir was Scala" "I would not recommend Elixir or Scala" It's not entirely clear whether your experience is only with Scala or whether you've used both. If it's the former then I'd suggest that others try Elixir for themselves rather than take a recommendation based on experience with another language.

By all means, I encourage everyone to learn Elixir, Scala, Haskell, or other similar, functional, immutable languages for personal growth. The points I raised earlier in the context of choosing a language for building a company apply to all of those. I don't see why Elixir is exempt - do you mind explaining?

> I don't see why Elixir is exempt - do you mind explaining?

Your points don't necessarily apply super well.

Point 1 is about hiring and teaching. There's going to be a different candidate pool of people interested in learning Elixir vs Scala, and while I don't know Scala my understanding (heh, see what I'm doing here?) is that it's a pretty large, complex language. So your experience onboarding and training new devs doesn't really apply. In particular your comment about "many ways to shoot yourself in the foot" doesn't resonate with me as an Elixir developer at all. It's a small, simple language, and there's really only one way to do most things.

Point 3 also doesn't necessarily apply. Yes, Elixir is smaller, but for all I know the libraries are better than in Scala or vice versa. I haven't run into too many missing libraries, and the ones we use are generally "production quality", though I don't really know what that means. They have tests, documentation, etc. But again, maybe that's a language culture thing. Dead simple testing, a great doc generation system, and compiler help, combined with general practices prevalent in the community, mean libraries are pretty robust and easy to use. Furthermore, erlang interop is super easy and done a lot. I know Scala has the JVM in principle, but I don't know to what extent you can lean on those libraries, to what extent it's typically done culturally, and to how smoothly they work with the rest of the code.

In short, I think "my Elixir was Scala" is an interesting take and worth sharing. But I think you're leaning too hard on that relationship, without clearly demonstrating that you know Elixir itself, in order to make strong recommendations against using Elixir.

Re: Elixir at Ramp

#36

Post by pmontra »

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 GenServer. I have no idea if there is a way around this except extensive logging.

Re: Elixir at Ramp

#37

Post by dnautics »

dorian-graph wrote: post #20
jklm wrote: post #2

To preface, I share a lot of the same sentiments as the author. My Elixir was Scala - learned it inside and out, then picked up Akka which taught me a lot of neat Erlang-derived principles. My favorite quote is "Make it work, make it right, make it fast," which is very close to the Armstrong comic. Having said that, I would not recommend Elixir or Scala or anything similar for startups. The 3 main reasons: 1) It's a…

As someone at a startup that is in Elixir, we haven't found 1 or 3 to be a problem. I would recommend Elixir for a startup. I made a similar comment on a previous article about Elixir: https://news.ycombinator.com/item?id=27194517

Oh hiring for Elixir is definitely a problem, but not a problem with the Elixir ecosystem. There are definitely startups with a management style/mentality that cannot handle what you need to do to hire successfully for Elixir in today's Elixir ecosystem. (To clarify: what it takes is "being a sensible human")

Re: Elixir at Ramp

#38

Post by dnautics »

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…

> I know that my GenServer failed at line x with data y, z but I don't know what sent that x to the GenServer. I have no idea if there is a way around this except extensive logging.

Ah, you were using casts instead of calls. Use calls as much as possible, even if you always send back :ok. This needs to be documented as part of best practices.

Re: Elixir at Ramp

#39

Post by busterarm »

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 its favor that make it worth exploring operationally, but also it doesn't really operate at that very large scale. It's well-adapted for smaller scale systems.

Re: Elixir at Ramp

#40

Post by strzibny »

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…

> It's well-adapted for smaller scale systems.

I wonder what they switch to at WhatsApp when they become medium scale.

Post reply on HN