4 ms·

Have you had any bad performance surprises ? To me, knowing that beam has poor pure computation performance made me look away. I don't want to build a magnifici

by bsaul 10y ago

Have you had any bad performance surprises ? To me, knowing that beam has poor pure computation performance made me look away. I don't want to build a magnificient immutable actor architecture only to end up writing parts of my system in C.

rvirding 10y ago
Erlang, and hence Elixir, was never optimised for raw computation, it's all about the massive concurrency (we can handle literally millions of processes), fault-tolerance and scalability. This is not surprising as no language is good at everything, you have to pick and choose what you is most important. In most systems different parts will have different requirements so I think it is perfectly reasonable to use multiple languages in a system. Erlang is very good at communicating with other languages/systems.
yellowapple 10y ago
I've had a few here and there, though usually the sorts of performance bottlenecks I encounter are resolvable with concurrency (which Elixir makes very easy). I don't really run into many situations where something is both inherently sequential and prohibitively slow (but I came from much slower languages like Perl and Ruby, so I ain't the best judge). My interest in ports/NIFs (and Rust as a specific implementation platform thereof) is less for performance and more for doing things that aren't really easy in a VM-driven architecture, like dealing with low-level device access or interfacing with native libraries/APIs. Basically: I'd try it first before dismissing it for supposedly-poor performance. There's a reason why Erlang is considered to be a "soft real-time" language, after all :)
- bsaul 10y ago
  Well, the other reason is that i feel the need for things like full OTP has decreased a lot since we've been using containers and cloud services that offer autoscaling, load balancing and health checks...
  - yellowapple 10y ago
    Sure, but those are (IMO) pretty clunky and broad-stroked compared to OTP, which handles quite a bit of that (and then some) on a much more intelligent and fine-grained level. Microservices are probably as close as one can get to matching OTP without basically reinventing OTP, and microservices often involve a lot of complexity (that's often in turn managed by tooling around things like Docker, but still). OTP is also not tied to a certain cloud provider; a couple of Raspberry Pi boards duct-taped to a WRT54G can use the same codebase, deployment practices, and application structure as a bunch of EC2 instances in a VPC with an Elastic IP. This is usually not true of "cloud" tools (things like Docker and Cloud Foundry are helpful here, granted, but a lot of the tooling around load balancing and such is often provider-specific).

by bsaul 10y ago

rvirding 10y ago

Erlang, and hence Elixir, was never optimised for raw computation, it's all about the massive concurrency (we can handle literally millions of processes), fault-tolerance and scalability. This is not surprising as no language is good at everything, you have to pick and choose what you is most important. In most systems different parts will have different requirements so I think it is perfectly reasonable to use multiple languages in a system. Erlang is very good at communicating with other languages/systems.

yellowapple 10y ago

I've had a few here and there, though usually the sorts of performance bottlenecks I encounter are resolvable with concurrency (which Elixir makes very easy). I don't really run into many situations where something is both inherently sequential and prohibitively slow (but I came from much slower languages like Perl and Ruby, so I ain't the best judge). My interest in ports/NIFs (and Rust as a specific implementation platform thereof) is less for performance and more for doing things that aren't really easy in a VM-driven architecture, like dealing with low-level device access or interfacing with native libraries/APIs. Basically: I'd try it first before dismissing it for supposedly-poor performance. There's a reason why Erlang is considered to be a "soft real-time" language, after all :)

bsaul 10y ago
Well, the other reason is that i feel the need for things like full OTP has decreased a lot since we've been using containers and cloud services that offer autoscaling, load balancing and health checks...
- yellowapple 10y ago
  Sure, but those are (IMO) pretty clunky and broad-stroked compared to OTP, which handles quite a bit of that (and then some) on a much more intelligent and fine-grained level. Microservices are probably as close as one can get to matching OTP without basically reinventing OTP, and microservices often involve a lot of complexity (that's often in turn managed by tooling around things like Docker, but still). OTP is also not tied to a certain cloud provider; a couple of Raspberry Pi boards duct-taped to a WRT54G can use the same codebase, deployment practices, and application structure as a bunch of EC2 instances in a VPC with an Elastic IP. This is usually not true of "cloud" tools (things like Docker and Cloud Foundry are helpful here, granted, but a lot of the tooling around load balancing and such is often provider-specific).