21–30 of 61 posts
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.
> [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.
Personally, I've never seen the value in private functions in the real world. If you are in the same runtime and can see the code, what exactly does a private function offer you other than ensuring somebody has to duplicate the method to manipulate it. Professionally I've never seen a private function/method that had a purpose or benefit from being private.
As far as benefit of something being private, an API does not have to be maintained if it is private. Once it's out there, you're locked into doing that for the duration of your deprecation window.
> [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.
Personally, I've never seen the value in private functions in the real world. If you are in the same runtime and can see the code, what exactly does a private function offer you other than ensuring somebody has to duplicate the method to manipulate it. Professionally I've never seen a private function/method that had a purpose or benefit from being private.
What's the largest number of people you've workwe with on a codebase? I would assume the benefits aren't really all that much for small codebases / teams.
> [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.
Personally, I've never seen the value in private functions in the real world. If you are in the same runtime and can see the code, what exactly does a private function offer you other than ensuring somebody has to duplicate the method to manipulate it. Professionally I've never seen a private function/method that had a purpose or benefit from being private.
In a statically typed language like Java, etc., it also gives you the benefit that when you are auto-completing or discovering methods, you see only the exposed methods you are meant to call as an API user instead of poring over every two-line helper method in the class.
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…
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…
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 protesting gains visibility which results in change.
Earlier quoted context omitted.
Personally, I've never seen the value in private functions in the real world. If you are in the same runtime and can see the code, what exactly does a private function offer you other than ensuring somebody has to duplicate the method to manipulate it. Professionally I've never seen a private function/method that had a purpose or benefit from being private.
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…
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…
I'm not sure why you want to compile Elixir or Erlang to JS... Most of the magic of the language is provided by BEAM and OTP which for a multitude of reasons cannot be properly implemented in any JS engine/backend I'm aware of. If anything I'd think the abstractions of Elixir/Erlang would be cumbersome and very awkward when writing performant code which had to be transpiled to JS. The biggest reason being is BEAM can…
Regarding your performance point, I'm skeptical. Is it really so easy to reason about the performance of even plain JS code? Maybe you're more familiar with the deep dark crevices of v8 and spidermonkey than I am, but I find v8 to largely be a black box in terms of fine tuning performance. Of course, the big picture optimization is simple enough, but that wouldn't change whether you are using plain JS, Opal, PureScript, or any other language.
Yes, a BEAM elixir program can run parallel threads and ElixirScript won't be able to do that because in JS, there are no threads. That doesn't make plain JS faster, just means Elixir will be brought down to the same level as plain JS.
I've used what I view to be equally foreign compile to JS languages (ClojureScript, Elm). They of course came with challenges, but fine tuning performance doesn't even make the top 10.
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…
I'm not sure why you want to compile Elixir or Erlang to JS... Most of the magic of the language is provided by BEAM and OTP which for a multitude of reasons cannot be properly implemented in any JS engine/backend I'm aware of. If anything I'd think the abstractions of Elixir/Erlang would be cumbersome and very awkward when writing performant code which had to be transpiled to JS. The biggest reason being is BEAM can…
One could imagine a compiler that inserts a yield around the calculation done in each Elixir AST node, and/or one which allows first-class representation of React components as Elixir processes, complete with JSX-like syntax. Very interesting to think about.
[0] https://github.com/acdlite/react-fiber-architecture
EDIT: Should also add that the shared-nothing messaging model translates very well to the requirements for Web Worker interop, so you actually could get multithreading.
Earlier quoted context omitted.
The trade off is that a runaway process can't compromise everything else. The inherent performance difference comes from prescheduling vs cooperative scheduling. Prescheduling is slightly slower in exchange for consistency in the face of bad behavior. Add in the supervision tree structure and you end up trading "super fast" for "very fast, consistent and runs forever"
Is there any updates on the JIT work from 2014 to help speed up raw performance of Erlang? [1] http://www.erlang-factory.com/static/upload/media/1402914329... [2] http://www.erlang-factory.com/euc2014/frej-drejhammar
Of course, if you want to sponsorise the work...