4 ms·
Drawbacks I see are: 1. no static typing. With typescript having taken off, and now even python and ruby becoming more and more feasible to use in production w
by cactus2093 6y ago
Drawbacks I see are:
1. no static typing. With typescript having taken off, and now even python and ruby becoming more and more feasible to use in production with static typing, switching to a new dynamic language is a hard sell for me.
2. limited ability to take full advantage of some of its unique features in many cases. The runtime and the included OTP library/paradigm has some really cool features with its approach to processes and concurrency with the actor model, and features like hot code reload. But IMO the industry and popular best practices have evolved in a different direction that make these things less compelling. Code deploys are a solved problem in any of the major vm/container runtimes, with blue/green deploys, canary builds, feature flags, etc. all quite easy to use, so hot code reloading isn't that compelling as a language feature anymore. There are tons of ways to orchestrate multiple instances of a services from Heroku to Kubernetes, and APIs built on Protobuf and GRPC, GraphQL, or json REST APIs, are now pretty standard for communicating between different services, or using message queues, kafka, cloud pub/sub, etc. Also the paradigm most developers are familiar with is stateless app servers that store any state in database or cache layers, which has a lot of benefits.
Erlang and OTP seem to kind of mix all of these paradigms together, and if you use all of its built-in ways of doing things you are really striking out on your own from the common "best practices" that more developers these days will be familiar with. A lot of common tooling and cloud hosting providers don't support Erlang OTP style programming natively. It can certainly be used successfully, I believe Whatsapp as one famous example was originally all written in Erlang, but I personally don't see a whole lot of justification for most apps to do this. Of course you don't have to use any of these features, but then why use a language if you're not going to lean into its unique strengths?
- joelbluminator 6y agoRuby really isn't becoming static though. Most code used by Rubyists (e.g Rails apps) is likely to remain dynamic.
- cactus2093 6y agoYeah, I can't really tell if the overall community will adopt it or not, but you may well be right. Last time I commented something about ruby not having static typing I got downvoted by people claiming Sorbet is already used heavily in production. But either way if I'm switching off of ruby, I don't really want to go to something else that doesn't have static typing.
- joelbluminator 6y agoA few huge companies like Stripe use Sorbet. Thats really not a good representation of Ruby users though. I guess youre right, for dynamicism Ruby is awesome but if you need types just switch to a true typed language.
- josevalim 6y ago> limited ability to take full advantage of some of its unique features in many cases Honestly, this shouldn't count as a downside. :) The way I frame it is "in the worst case scenario, you can deploy Erlang/Elixir as you would any other language". You don't need to use distribution, you can still build stateless apps, etc. And yes, almost nobody uses hot code swapping! However, whenever you need a specialized solution, such as quick messaging between servers, proper concurrency so a slow upstream server doesn't kill your app, etc... you have that at your fingertips! Even if you are not using any of that in production, you are still leveraging concurrency when compiling code, running tests, etc. It really makes a large difference! And if for some reason you cannot leverage any of that either, the languages are still great on their own. Pattern matching and immutability are a joy, developers feel productive within the existing frameworks, and so on. My car can go 260km/h but I never went past 140km/h (speed limit where I live) and I still love it (the best car I ever had).
- amattn 6y agostatic typing is what drew me to go, Elixir isn't a static-typed language, but there are plenty of guardrails in the language that make up for it. Pattern-matching, guards, good compiler messages, casting, etc. You've also got fantastic testing framework, and good conventions like tagged tuples {:ok, x} vs {:error, y}. On top of all of that, you've got the Erlang underpinnings: immutability, crash-fast, app umbrellas, etc. It's a very safe language to develop in. I don't miss the strict static typing at all.
- realusername 6y ago> 1. no static typing. With typescript having taken off, and now even python and ruby becoming more and more feasible to use in production with static typing, switching to a new dynamic language is a hard sell for me. While it's true that Elixir is a dynamic language, there's much less "magic" compared to Ruby or PHP, the language server has good autocompletion and warnings.
- conradfr 6y agoThere's not a lot of magic in php nowadays with strict typing and unions. Warnings at compile time are a plus yes.
- strzibny 6y ago> limited ability to take full advantage of some of its unique features in many cases. The runtime and the included OTP library/paradigm has some really cool features with its approach to processes and concurrency with the actor model, and features like hot code reload. But IMO the industry and popular best practices have evolved in a different direction that make these things less compelling. Think about it this way. You already reap a lot of benefits by just handling requests with Phoenix. Pre-emptively scheduled light-weight processes that does not have to run GC in most cases is already a huge win. Don't you think? You certainly don't have to be 100% buy-in in every single OTP or Beam feature. Really. Actually, it makes sense to do things "the old" way when you feel more confident about them.
- jolux 6y agoElixir has @spec and Dialyzer and we enforce using it where I work.