Elixir v1.4.0 released • Hacker News Board

Re: Elixir v1.4.0 released

#11

Post by bryanjos » Thu, Jan 05, 2017, 1:51 AM UTC

pmarreck wrote: post #4

pmontra wrote: post #3

Earlier quoted context omitted.

If all you need in js/wasm is the functional layer of the language, that could be easy. If you want to add processes, that could be very hard. If you also want the supervisors, that's difficult but probably not has much as adding Erlang style processes.

What's stopping a compile of Erlang to JS via LLVM and Emscripten and just taking the expected performance hit?

There is the LLVM backend in Erlang as of version 17. I haven't seen much info on it. I haven't seen anyone try to go the whole process from Erlang code to LLVM to Emscripten to JavaScript. I am interested to know what hurdles there might be, performance, etc.

Re: Elixir v1.4.0 released

#12

Post by transfire » Thu, Jan 05, 2017, 2:08 AM UTC

> [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.

Re: Elixir v1.4.0 released

#13

Post by jkmcf » Thu, Jan 05, 2017, 2:57 AM UTC

transfire wrote: post #12

> [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.

You'd think they'd learn from Java!

Edit: Not a shallow dig, but I had lots of fun using a 3rd party library that had locked down a lot of methods which prevented some sales driven features...

Re: Elixir v1.4.0 released

#14

Post by securingsincity » Thu, Jan 05, 2017, 3:28 AM UTC

> [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.

Re: Elixir v1.4.0 released

#15

Post by tiffanyh » Thu, Jan 05, 2017, 3:43 AM UTC

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.

Re: Elixir v1.4.0 released

#16

Post by qaq » Thu, Jan 05, 2017, 3:45 AM UTC

tiffanyh wrote: post #15

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.

No, same as Go will never be able to match the unique characteristics of Erlang/OTP.

Re: Elixir v1.4.0 released

#17

Post by qaq » Thu, Jan 05, 2017, 3:47 AM UTC

josevalim wrote: post #8

Link to the official announcement: http://elixir-lang.org/blog/2017/01/05/elixir-v1-4-0-release...

Thanx for all the great work José we all really appreciate it.

Re: Elixir v1.4.0 released

#18

Post by brightball » Thu, Jan 05, 2017, 3:53 AM UTC

tiffanyh wrote: post #15

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.

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"

Re: Elixir v1.4.0 released

#19

Post by brightball » Thu, Jan 05, 2017, 3:57 AM UTC

transfire wrote: post #12

> [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.

Re: Elixir v1.4.0 released

#20

Post by tiffanyh » Thu, Jan 05, 2017, 4:03 AM UTC

brightball wrote: post #18

tiffanyh wrote: post #15

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.

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