Elixir at Ramp

https://engineering.ramp.com/elixir-at-ramp/

by clessg • 5 years ago

126 42 5 years ago

engineering.ramp.com

jklm3• 5 years ago

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 hiring problem.

There aren't enough qualified people who can fill these roles. Expect a lot of on-the-job training that's more challenging than you'd think since these languages/frameworks are different paradigms. Famously, the complaint I heard in Scala circles was "There are too many ways to shoot yourself in the foot." I worked at a well-known everyday consumer tech company where the payments platform went down for the better part of a day as people scrambled to figure out what went wrong. Noone had read the de-facto Scala bible which warned that catching `Throwable` could break your code.[1]

2) You really, really don't need to get things perfectly right from the get-go.

My hot take about most dynamic languages is that they are a poor fit for startups who have intentions of being long-term businesses: you’ve created an environment that’s optimized for your founding engineers to build something quickly in the first 7 months, but the price is a set of recurring obstacles which your engineers will pay down over the next 7 years.

With rare exceptions, most companies throw away or rewrite their initial infra once they hit scaling issues. Having these scaling issues means you've likely hit product-market fit, secured more funding, and hired a badass team to solve said scaling issues.

3) The ecosystem is smaller.

Because the language/framework is deeper, it requires more investment to learn. In turn, fewer production-level libraries get built on top of it. That's when you end up needing to build a lot of things yourself. At which point - you've slowed down _even more_ vs. DynamicLang where you can run `dynamic-package add audit-trail` or something and get the 80/20 solution in 5 minutes.

[1] http://www.tzavellas.com/techblog/2010/09/20/catching-throwa...

hggythhdtr• 5 years ago

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

jklm3• 5 years ago

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?

dasil003• 5 years ago

With Scala you're still dealing with a JVM baseline though. You don't get the Erlang/OTP foundation that means the entire ecosystem and tooling down to operations and VM introspection are built around this actor model. It's a very different situation from Scala where you're a second-class citizen in the foundational ecosystem.

That said, I agree with you if you are planning to be a unicorn and scale to 1000+ engineers then you definitely should go with the well-worn path just because it's the only way to satisfy your insatiable hiring funnel.

On the other hand, if your aspirations are to focus on a simple but great product and keep the team tight rather than chase growth at all costs, Elixir/Erlang could be a super power to scale a cohesive product to massive scale with a very small team (eg. WhatsApp).

travisgriggs• 5 years ago

I would not recommend Elixir or Scala or anything similar for startups.

What about for not-startups (whatever those are)? I'm attempting to use Elixir for a new component of a kind of startup like product in a 50 year old company. So kinda startupie, kind very not. But more generally, I'm curious what changes with the "for startups" qualifier?

sethherr• 5 years ago

Are you looking for product market fit? If so, you need to focus on that and not scaling.

If you have a guaranteed internal market so you need to launch with scale, then that’s more important

lostcolony2• 5 years ago

What are you hoping to gain by using Elixir? I used it in a non-startup years back specifically because of the reliability; we needed a system that, for all intents and purposes, did not go down, and we needed to build and support it with a small team. It worked beautifully for that.

lostcolony2• 5 years ago

' My Elixir was Scala '

So...not Elixir.

I think your first and third bullets are correct, but not entirely relevant.

That is, yes, it's hard to find people that know Elixir already, but if you can take a dev and get them competent in two weeks does it matter? Your experience with Scala != experience with Elixir.

Likewise, when it comes to ecosystem - maybe it matters, maybe it doesn't. In Scala you can leverage the JVM; I feel like the ecosystem isn't really a problem then. In Elixir, you have a lot of things available both natively in Elixir, and in Erlang. Less than the JVM, for sure, but unless your problem domain includes something that doesn't exist for Elixir, it doesn't matter.

For your second...that seems more how you write code than your language choice. And a claim that Erlang/Elixir's approach to 'let it fail' means you are spending too much time writing robust code seems...false; if anything it's less than having to catch and think about Java's checked exceptions, let alone if you ever ask "wait, what happens if we go off the happy path here?"

andy_ppp• 5 years ago

I think you should have better hiring practices if you think people you’re hiring can’t learn new things. Ideally you want your employees learning to be better all the while.

There are also upsides that you have to weigh up when choosing a language. I don’t find your arguments particularly persuasive.

cies3• 5 years ago

So what do you recommend? Rust? JS? TS? Java? C++?

I'd not recommend Scala for other reasons: being multi paradigm makes it hard to learn, read, re-read and collaborate on. Kotlin would be a more sensible choice on the JVM imho (no implicit nulls, fully OO at the core with FP where it makes sense in that context, sum-types, exhaustiveness checks, no exception/annotation frenzy like Java).

And Erlang misses types. Gleam[1] looks cool, and seems to be picking up steam.

Rust is an amazing choice if you need that kind of low-level control over performance in all it's dimensions (except built times).

[1] https://github.com/gleam-lang/gleam

papito2• 5 years ago

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.

dragonwriter• 5 years ago

Expect a lot of on-the-job training that’s more challenging than you’d think since these languages/frameworks are different paradigms.

“Different” than what? Its not the 1990s where everyone learns only C++/Java-style static class-based OOP anymore.

I worked at a well-known everyday consumer tech company where the payments platform went down for the better part of a day as people scrambled to figure out what went wrong. Noone had read the de-facto Scala bible which warned that catching `Throwable` could break your code.

That’s a pretty horrid example for “Scala is a hiring problem because its a different paradigm”; lesson one for exception handling in every language I’ve used that has exceptions is never catch everything, only catch specific exceptions that you know what to do with. And in virtually every language, catch-everything is a minefield waiting to blow up in your face.

dorian-graph• 5 years ago

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

dnautics2• 5 years ago

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

halfmatthalfcat2• 5 years ago

I'm starting a startup with Scala and Akka. I'm doing this because I tried doing the same thing with Node and before then Java, but both the language and ecosystem could not help me (solo founder) move fast enough or give me confidence that my architecture was going to last a couple years down the road.

I also didn't want to make things "just work" and refactor later, because I think that's just overall terrible advice. The cost of going back and rewriting your architecture is enormous. Might as well use tools you feel confident can scale with your startup than hack something together and have a complete mess on your hands.

brainless• 5 years ago

I'm from Python and JavaScript lands and I'm currently learning Rust very slowly.

There are many reasons why I feel Erlang or Go or Rust shines brighter in many situations but my issue is that I not only need to get up to speed, build scrappy prototypes fast, but also hopefully, hire other engineers including juniors.

There are many ways one can build systems with multiple languages and take the benefit that each has to offer in specific cases. Python itself calls C in multiple libraries to speed up code.

Some of the safety related paradigms are really practical but to adopt a new language means a lot of risk for the startup too. Not every tech leader is so capable as to juggle both the delivery stress of features and building idiomatic software in a new language, I know I would struggle.

So I keep learning and I will wait for when specific cases demand me to use another language and use something like gRPC in between my existing codebase and the one in a new language. I do not (should not) have to move away from what already works well to adopt new tools or paradigms.

pmontra2• 5 years ago

IHMO junior develpers are not a problem. A customer of mine hired a developer at his first job after university. He graduated in Mathematics with some college level expertise of Java. We gave him an Ubuntu VM with Elixir and our Phoenix project and he learned to work and to use the language (the former is more difficult than the latter.) I think that learning Elixir was as difficult for him as it would have been learning any other language, including Java in a real world environment.

The problem could be with senior developers: if we had no experience with Elixir we probably would have resisted starting a new project (the main project of the company) with a new language. But this is the same with any language. Would I be confident to build a company on Python or Ruby or JS if I didn't know them well? Not at all. Would I start with Java? Not after all the years I have not used it.

nickjj• 5 years ago

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 their ex-engineers last month about how they build and deploy their set up at: https://runninginproduction.com/podcast/82-dropbox-gives-you...

Then there's Basecamp which is one of the oldest SAAS apps around using Rails and GitHub too which isn't quite as old but definitely falls into the long term business category.

yen223• 5 years ago

Unless something has changed, I believe Instagram is still on Django

danpalmer2• 5 years ago

They are a heavily custom fork from a very old version of Django, but apparently much is still "recognisably Django".

danpalmer2• 5 years ago

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.

JeremyNT• 5 years ago

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.

busterarm3• 5 years ago

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.

strzibny• 5 years ago

It's well-adapted for smaller scale systems.

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

joelbluminator• 5 years ago

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.

strokirk2• 5 years ago

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 situational/subjective benefits. I find the import system in Elixir to be very opaque, making it hard to know where a function is coming from after it's been aliased and use:d. I subjectively find explicit import statements much clearer when debugging code.

The final drops for me are the missing explicit return statement, and the extraordinarily bad tracebacks on error. If I could I would excise Elixir from our company.

chartpath• 5 years ago

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 into a language doesn't really help with web startups that aren't targeting large scale consumer traffic or systems level apps, and even if it did, multiprocessing GIL languages has never been an issue. It's a cool feature for sure, but language fundamentalism is just a way for insecure devs to feel cooler.

hnedeotes2• 5 years ago

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.

agd• 5 years ago

Regarding explicit vs implicit imports, elixir supports both. However explicit aliases are preferred both for clarity and compilation speed. Perhaps discuss with your team why they are (seemingly) preferring to import rather than alias?

pmontra2• 5 years ago

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.

dnautics2• 5 years ago

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.

strokirk2• 5 years ago

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.

Elixir at Ramp

Related Stories