defmodule A do
defstruct [...]
end
defmodule B do
defstruct [...]
end
defprotocol C do
def foo(a, b)
end
defimpl C, for: Any do
def foo(x1 = %m1{}, x2 = %m2{})
Module.concat(m1, m2).foo(x1, x2)
end
end
defmodule A.A do
def foo...
end
defmodule A.B do
def foo...Write a typical computation such as Fibonacci in Java and Erlang/Elixir and compare. Fortunately someone has already done this.
Elixir is 3x slower than C and 2x slower than Java for this single thread example.
https://github.com/drujensen/fib
Apparently this upsets people for me to point this out. However, I did not say that Elixir was slow in general or a bad choice. It's an excellent choice for problems which suit parallelization or which require reliable, consistent performance.
Since the parent poster had commented that adding this multi-module dispatch would not be performant, I merely pointed out that the single thread peformance was already slow (as in, why worry too much about the performance cost of the multi dispatch suggestion).
It used to be that on HN you down-voted for people who were obstructing conversation, being disingenuous or in some cases being excessively disrespectful.
Now having read 3 of your comments and seeing all 3 are heavily down-voted and yet the content of your messages is constructive and interesting.
If you disagree with something, fine, just don’t vote on it. Save the down-votes for bad actors, not someone with a different view.
The last thing HN needs is to become the kind of place where you’re actively encouraged to karma farm or whatever that term is for that behaviour on reddit.
I always made my statements the way I feel like, since the BBS days, and voting systems haven't change that.
There will always people that want to silence you, regardless of the medium.
Life is too short to care for them.
When was the last time you needed to write a Fibonacci for anything you’ve built in your career?
It’s a benchmark that doesn’t show anything useful for real world applicability.
I said per-thread, but I meant single-thread... as in CPU bound single process activity. That is undisputedly slow compared to languages like Java, C/C++, Go, etc. That is also very much not what Erlang is designed for. It adds a lot of overhead with the supervisor and other features which do not give a benefit for single thread CPU heavy activities.
And since the parent poster mentioned the multi-dispatch approach would not be performant, I attempted to suggest that the performance cost of that would be less relevant considering Elixir is already not very performant in single thread cases. In other words, it was a moot point.
I never said that Elixir/Erlang was slow for multi-thread/process distributed activities. Obviously that is where it really excels. But if you want to crunch numbers sequentially in a way that cannot be spread across multiple processes/threads, then you will find Elixir to be slow.
The benchmarks you are referring to are very much multi-thread comparisons. They are specifically NOT what I was was slow.
I don't agree that performance is a moot point if what you use is slower than some alternatives, and I think that's the main point where we disagree.
But if this really is a big deal, then it would be fair to consider the other language features which do not contribute to the reliability, scalability, and other core Erlang/BEAM features. For example, what is the cost of pattern matching in general? Doesn't that add considerable overhead, just for the benefit of making code cleaner? If that's acceptable, then I don't see why "just one more" feature - in this case a homegrown multi-method dispatch across modules - should be considered non-performant.