Will Erlang/Elixir ever be able to attain the raw performance speed of Go? I'm not talking about concurrency, etc. Just raw computational speed.
probably not. on mostly io bound workloads they should perform similarly but a beam instruction is inherently more costly than a go instruction so on cpu bound workloads go should dominate
however, if you're using elixir/erlang for something cpu bound you're probably doing something very wrong so this isn't a real world concern for most users
What's stopping a compile of Erlang to JS via LLVM and Emscripten and just taking the expected performance hit?
Erlang doesn't compile to machine code, but to bytecode that runs into the Erlang VM. So you would probably have to run the Erlang VM on top of javascript... I'm not sure whether it's possible, but it sure sounds heavy.
With WebAssembly, you should be able to compile the Erlang VM itself to it.
> [Kernel] Deprecate support for making private functions overridable. Overridable functions must always be public as they must be contracts Just lost interest. I thought Elixir was supposed to learn from Ruby.
A function being overridable is a part of the contract, because other functions may rely on it. If you can override truly private stuff, you have no idea about the invariants that you need to uphold to do that correctly.
> [Kernel] Deprecate support for making private functions overridable. Overridable functions must always be public as they must be contracts Just lost interest. I thought Elixir was supposed to learn from Ruby.
Am I misunderstanding this or what do you mean learn from ruby? In Ruby I can override private methods without a problem.
My favorite part about Elixir is that it doesn't try to reinvent the wheel. It's not an untested, trendy new paradigm or tool. It's based on decades of Erlang/BEAM/OTP experience and Ruby/Rails/last 10~ years of programming ergonomics. The only things that are added are those that actually add to the experience. An example: A large part of the Erlang standard library is not translated in Elixir. Instead, you call Erl…
What's wrong with getting excited about a new language and framework that's better? Being vocal about how awesome something is gets people involved which grows the community. A larger community translates to more educational material and tooling. I think zealotism has a fine line, but I don't think it's all bad. It's almost like protestors that believe in something strongly. Sometimes they cross the line, but them pr…
Coming from Ruby, Elixir feels like a powerful, beautiful language with a surprisingly radical but ultimately simple approach to concurrency thanks to Erlang/BEAM, and Phoenix is like Rails 2006, as far as the framework to sell Elixir's advantages to the masses. It's very powerful and scaling "just works". All Elixir needs now is a viable ElixirScript that can compile down to JS/WASM, and along with Nerves it's ready…
Just use elixir on the server, and clojurescript on the client.
> [Kernel] Recognize merge conflict markers in source and provide a readable error message Great idea, having to track down a merge conflict that may have been committed can be a drag.
This confuses me, as I can think of any language where `I'd say the compiler or interpreter should tell you within no time where it encountered invalid tokens?
What's wrong with getting excited about a new language and framework that's better? Being vocal about how awesome something is gets people involved which grows the community. A larger community translates to more educational material and tooling. I think zealotism has a fine line, but I don't think it's all bad. It's almost like protestors that believe in something strongly. Sometimes they cross the line, but them pr…
Better than what?
Erlang was developed to solve problems that are quite common in Web Development like concurrency, high availability and so on. I see Elixir basically as a user-friendlier version of Erlang with some added goodies. So I think it makes perfect sense for it to be popular among the Web crowd.
It definitely has it's own problems(ease of deployment, package maturity, imo). But if your problem involves networks I think Elixir is at the very least worth having a look at.
> [Kernel] Deprecate support for making private functions overridable. Overridable functions must always be public as they must be contracts Just lost interest. I thought Elixir was supposed to learn from Ruby.
Can you please expand on this a bit? Your comment is very vague.
The comparison with Ruby here doesn't make much sense because private means different things in both languages and Elixir does not have inheritance.
There are plenty of times. Take a data structure like a hashmap. You know there are plenty of internal functions to manage the map (rehash, handle collisions...) that there is no reason for a hashmap end user to see or even be tempted to muck with. Now, you can could make a new class as an interface to this hashmap with only the appropriate exposed methods...but that seems like an excessive sort of pattern. In a stat…
When I subclass hashmap, I may desperately want to reimplement collision handling without also having to rewrite the every other private function it calls. Private functions close the library off to custom extension.
... and keeps the library's updates smoother, since there can't be any tinkering with library's implementation.