8 ms·

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 n

by jklm 5y 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-throwable-in-scala/ http://www.tzavellas.com/techblog/2010/09/20/catching-throwa...

hggythhdtr 5y 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.
- jklm 5y 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?
  - hnedeotes 5y ago
    I think it's sort of obvious what the parent comment is saying? You gave an example of your experience with a different language, that has really not much bearing on the one being talked about. It runs in a different VM, it's a different paradigm (or mash-up of paradigms which, in turn, is the source of one of your contention points when learning/ramping hires), it's a statically typed language so requires usually more upfront thinking and a better understanding of domain modelling (getting it right from the start), it's notorious for being complex (don't know if it's warranted or not, but it's a normal complaint even from people who seem to like the language). Elixir/Erlang does need a bit of honest study to hone (this is the same with everything though, JS for instance is quite complex when you take a step back and look at what you need to understand to write decent maintainable code), but the payoff is much higher because it doesn't change with every tide. Code you wrote 4 years ago, if idiomatic, will be idiomatic today, and I'll go off on a limb here and say it will be in 4 years time too. (btw didn't downvote you)
    - jklm 5y ago
      To be fully clear - for how they align with the 3 points I raised, Ruby/Node/Python fit into 1 bucket (no, yes, no) and Scala/Elixir/Haskell fit into another (yes, no, yes). I'm not trying to derail into discussing how Scala is a shade better or worse than Elixir in some aspect - the main point I'm trying to drive home is that they're both in an entirely different class compared to Ruby/Node/Python.
  - R0b0t1 5y ago
    Elixir is easier to learn. I say this having learned Erlang first. I don't know what caliber of hire you're being presented with, though.
dasil003 5y 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 5y 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 5y 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
- lostcolony 5y 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.
lostcolony 5y 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?"
dorian-graph 5y 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 https://news.ycombinator.com/item?id=27194517
- dnautics 5y 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")
andy_ppp 5y 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.
cies 5y 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 https://github.com/gleam-lang/gleam
- papito 5y 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.
  - cies 5y ago
    This is exactly my experience. Like C++, a Scala project needs a document describing what parts of the languages should not be used, or avoided in most cases. There is a great danger in this. Hence I prefer a language that is smaller and helps me to avoid cruft being checked in to version control. Linters are a solution, I've seen it work in JS/TS project. Not sure if C++/Scala have linters up to the feature level of JS/TS linters.
  - halfmatthalfcat 5y ago
    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.
    - cies 5y ago
      > you can potentially cut your development team by some large factor Compared to what? Java? Kotlin? And only initial development? Or also maintenance? And why potentially and not certainly? What can make that difference?
dragonwriter 5y 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.
halfmatthalfcat 5y 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.

by jklm 5y ago

hggythhdtr 5y 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.

jklm 5y 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?
- hnedeotes 5y ago
  I think it's sort of obvious what the parent comment is saying? You gave an example of your experience with a different language, that has really not much bearing on the one being talked about. It runs in a different VM, it's a different paradigm (or mash-up of paradigms which, in turn, is the source of one of your contention points when learning/ramping hires), it's a statically typed language so requires usually more upfront thinking and a better understanding of domain modelling (getting it right from the start), it's notorious for being complex (don't know if it's warranted or not, but it's a normal complaint even from people who seem to like the language). Elixir/Erlang does need a bit of honest study to hone (this is the same with everything though, JS for instance is quite complex when you take a step back and look at what you need to understand to write decent maintainable code), but the payoff is much higher because it doesn't change with every tide. Code you wrote 4 years ago, if idiomatic, will be idiomatic today, and I'll go off on a limb here and say it will be in 4 years time too. (btw didn't downvote you)
  - jklm 5y ago
    To be fully clear - for how they align with the 3 points I raised, Ruby/Node/Python fit into 1 bucket (no, yes, no) and Scala/Elixir/Haskell fit into another (yes, no, yes). I'm not trying to derail into discussing how Scala is a shade better or worse than Elixir in some aspect - the main point I'm trying to drive home is that they're both in an entirely different class compared to Ruby/Node/Python.
- R0b0t1 5y ago
  Elixir is easier to learn. I say this having learned Erlang first. I don't know what caliber of hire you're being presented with, though.

dasil003 5y 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 5y 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 5y 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
lostcolony 5y 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.

lostcolony 5y 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?"

dorian-graph 5y 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 https://news.ycombinator.com/item?id=27194517

dnautics 5y 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")

andy_ppp 5y 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.

cies 5y 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 https://github.com/gleam-lang/gleam

papito 5y 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.
- cies 5y ago
  This is exactly my experience. Like C++, a Scala project needs a document describing what parts of the languages should not be used, or avoided in most cases. There is a great danger in this. Hence I prefer a language that is smaller and helps me to avoid cruft being checked in to version control. Linters are a solution, I've seen it work in JS/TS project. Not sure if C++/Scala have linters up to the feature level of JS/TS linters.
- halfmatthalfcat 5y ago
  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.
  - cies 5y ago
    > you can potentially cut your development team by some large factor Compared to what? Java? Kotlin? And only initial development? Or also maintenance? And why potentially and not certainly? What can make that difference?

dragonwriter 5y 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.

halfmatthalfcat 5y 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.