5 ms·
> ... with 1/50th the effort of any other language. To junior developers reading this, such statements are never true.
by jeswin 3y ago
> ... with 1/50th the effort of any other language.
To junior developers reading this, such statements are never true.
- knewter 3y agoThough if people consistently over decades sing a language's praises on a single point consistently like they do the beam on this point, it's usually not without merit
- javanonymous 3y agoThey wrote it from scratch with the benefit of all the knowledge they had gathered after running the old system for years. A 2X improvement would not be surprising to me, even if they had rewritten it in the same language. . According to others in this discussion they also made architecture changes (DB, Kafka etc.). Do we know if that improved the performance? There is no objective way we can tell if Elixir had any performance impact. It could have been due to the rewrite, the architecture change or a combination of both.
- ch4s3 3y agoNot to just toss around anecdotes, but I once rewrote an email service in elixir for a company from a literal sketch on a piece of printer paper describing what their old system did. The new service ran on 1 server vs half a dozen and was both faster at crunching through their mail queue and used far fewer resources. Some tasks are embarrassingly parallelization and the BEAM excels at those tasks. Sure you might want features it doesn't have for certain systems, but for some things it really is the right tool.
- pessimizer 3y agoWhatsapp took over the world running on Erlang/BEAM, with barely any servers and a few engineers. I honestly don't know what could be a better success story than that, but Discord has also done pretty well. The BEAM + Rust combination is looking scarily effective right now.
- ch4s3 3y agoI'd be willing to accept the argument that Whatsapp happened to have assembled an uncommonly good team, but it is a signal. Yeah the BEAM with some Rust NIFs is a great combo. I'd definitely consider it in the future for many types of problems and anything involving a HTTP or GraphQL interface.
- weatherlight 3y agoElixir/BEAM's (Erlang Virtual machine) frugality isn't just theoretical; it's got real-world creds. Originally tailored/optimized for 1980s telecom switches (a fleet of single core extremely low powered machines.) Fast forward, and you've got a setup that's less demanding on your A/C and optimizes multi-core usage like a champ. it utilizes the same concurrency abstractions whether its 2 cores across two machines or 64 cores on the same machine, it makes no difference to the BEAM Take the hot code reloading and actor model-based concurrency as a prime example. It's like getting AWS-level functionality without the steep bill for a lot of companies. Though, I gotta admit, it used to be a hard sell for CPU-heavy workloads, especially number crunching. But Elixir is stepping it up with their Nx library, so that's changing. Examples of companies cashing in on BEAM's efficiency: Bleacher Report: Went from 150 servers down to 5. No joke. Discord: Handles millions of real-time users without breaking a sweat or the bank. Financial Times: Their content recommendation engine got both efficient and cost-effective. Change.org: More petitions, fewer servers. Podium: A million SMS messages a day and didn't have to massively scale hardware.
- twelve40 3y ago> a fleet of single core low, extremely powered machines. what are "extremely powered machines"? > It's like getting AWS-level functionality without the steep bill which part of AWS functionality? load-balancing Beanstalk-style is free. AWS compute is not free, but neither is compute free with Elixir or whatever stack you run.
- weatherlight 3y agosorry i meant (low powered*) typo
- weatherlight 3y agoTotally get your point about AWS having free-tier services and compute never being free, regardless of the stack. My point wasn't that BEAM offers free compute, but rather that its inherent features can sometimes make certain AWS services redundant. For instance, Elixir has built-in fault tolerance with its actor model and supervision trees. This means that even when a process fails, it gets rebooted automatically without messing up other processes—kind of like what you'd use Auto Scaling and backup services for on AWS. Similarly, distributed Erlang allows Elixir to run across multiple nodes. This could cut down the need for extra AWS instances or orchestration layers like Elastic Beanstalk. And when it comes to deployments, Elixir's hot code swapping can simplify what might otherwise require rolling updates or blue-green deployments with Elastic Load Balancers in the AWS ecosystem. On the concurrency front, Elixir is designed for handling a high number of users and tasks simultaneously, which might reduce your reliance on EC2 or Lambda. Phoenix, Elixir's web framework, even has real-time capabilities baked in, so you don't need extra services like AWS WebSockets for that. Finally, Elixir's actor model can serve as an in-memory message queue, which could potentially negate the need for something like AWS's SQS. So, while you're still incurring compute costs, the need for additional AWS services could be lessened, thereby simplifying your architecture and perhaps lowering overall costs.
- fsloth 3y agoIt does not sound too incredible to me. Erlang and BEAM was designed to handle Ericson's telephony services. Piping-lots-of-stuff-in-parallel in fault tolerant fashion is the main use case around which it was designed. Of course this is anecdotal.
- pdimitar 3y agoWhat's your counter-argument?
- wredue 3y agoThey don’t need one. When a person makes a claim, especially such a ridiculous one, it is perfectly valid to outright reject that claim without any argument. Why? Because no argument was provided in the first place.
- pdimitar 3y agoWell, I am trying to be better than them. Also I dislike FUD spreading so there's that, I am trying to engage them in a more-informed manner. Though I am not sure whom you are addressing, my parent poster or theirs.
- coldtea 3y agoYes, this is what we call in the industry as "overhype"
- sph 3y agoIf I had said 1/4th the effort would that have invalidated my argument? I pulled that figure out of my arse from experience. YMMV. You'll note I'm not selling anything here, and no one is paying me a commission. A junior that got "swindled" by my claims and spends a weekend learning Elixir becomes a better programmer and earns another feather on their cap. How tragic. Junior devs, if you want to become a senior greybeard like me, learn anything that tickles your fancy, and ignore anyone that says it isn't worth your time. Even learning COBOL will make you a better programmer. I can only promise that Elixir is more fun than COBOL.
- Horffupolde 3y agoHe just means that junior developers don’t understand hyperboles because they don’t have the intuition yet.
- Name_Chawps 3y agoI'm a junior Elixir dev. I write concurrent code without much extra effort compared to non-concurrent code. Elixir makes it easy.
- eropple 3y agoYou can do that easily in modern Java--even for older JVMs, tools like Netty and later Vertx have been around forever. Or in Node, even more easily. Elixir/BEAM do have some benefits that are worth considering for many projects. But they absolutely are not special in this regard, and that's the junior-developer trap about which the person to whom you replied was referring.
- Volundr 3y agoJava, kind of with Akka or similar, although even with that one always be aware of blocking. Loom should help. Node: not really unless something dramatic has changed. Using 32 cores is going to require 32 separate node (OS level) processes, and your on your own for providing communication between them, plus callbacks aren't near as intuitive as the BEAM process model (think green threads)
- eropple 3y agoRe: Node - most waiting in most web applications is IO-driven, but yes you do want to run under a process controller.
- Volundr 3y agoI mean sure, but given the topic at hand is getting performance out of your 32-core server, I'm not sure that's a super relevant observation. "I've been given way more hardware than I need" is an entirely different problem I think most of us would be happy to tackle.
- collaborative 3y agoI'm a seasoned Java and Node developer, but have never touched Elixir/Erlang. Could you spell out for me the benefits Elixir provides over Java concurrent code? Is it actually a performance gain, or simply a nicer syntax? I am a bit confused by the claims of this post and of the earlier comment. Thanks a lot
- b33j0r 3y agoTo senior developers reading this, such statements are never true ;)
- mowthie 3y agoTo non-developers reading this, I have no way of knowing whether such statements are ever true, but I am willing to believe they are not!
- bsder 3y agoTo all junior developers--this developer doesn't know what he is talking about. Erlang and BEAM, the things underlying Elixir, were specifically engineered to be used in a reliable, distributed fashion including a gigantic amount of idioms and support that no other language comes close to. Erlang's bit syntax is hands down the best byte stream serialization that still exists--both from a perspective of performance as well as expressiveness. OTP is a documented set of idioms and behaviors for building systems that are meant to be highly distributed and deal with failure gracefully. These include things behaviors like in-place upgrades, supervisors which shut down and restart failing processes, error delegation, etc. Erlang was meant for genuine "five nines" reliability. No other language comes close (maybe Ada does--I'll let their proponents chime in about that).
- jakylbf 3y ago[dead]