Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir v1.4.0 released

github.com

Post reply on HN
Print view View original

41–50 of 61 posts

Re: Elixir v1.4.0 released

#41

Post by barrkel »

brightball wrote: post #19
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.

Private functions permit functional decomposition without a commitment to support the interface implemented by the private functions (meaning the functions can be changed / refactored without breaking clients of the library).

Re: Elixir v1.4.0 released

#42

Post by lawik »

pmontra wrote: post #3
themgt wrote: post #2

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…

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.

AFAIK the VM creates a thread per core (by default) and schedules Processes across those threads and stuff. I'd say this might be possible to do with Web Workers. Sounds like it could be fun, probably a challenge to make it fast.

Re: Elixir v1.4.0 released

#43

Post by xiaoma »

sotojuan wrote: post #10

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…

It's actually very much like the situation was with Rails a decade ago. Actually that was more extreme. Anybody remember all those "Rails vs _____" commercials from the Rails Envy people?

https://www.youtube.com/watch?v=Y7Jte6NvLGU

Re: Elixir v1.4.0 released

#44

Post by the_duke »

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.

Go is statically typed and compiled, while Elixir/Erlang is dynamically typed and interpreted, so beating Go is unlikely.

A plus for BEAM is that each process (aka Goroutine) has it's own, independent garbage collector that doesn't interfere with anything else.

The point is, though, you don't use the BEAM for it's raw speed, but for it's great concurrency and fault tolerance. Go has decent concurrency, but it's not all roses and butterflies. Also all data is immutable in Erlang/Elixir which makes concurrency a lot easier.

Re: Elixir v1.4.0 released

#45

Post by dublinclontarf »

xiaoma wrote: post #43
sotojuan wrote: post #10

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…

It's actually very much like the situation was with Rails a decade ago. Actually that was more extreme. Anybody remember all those "Rails vs _____" commercials from the Rails Envy people? https://www.youtube.com/watch?v=Y7Jte6NvLGU

I started using rails pre 1.0 when in university, inexperienced as I was I totally drank the coolade.

I remember laughing to myself thinking how much more productive I would be than my classmates.

Boy was THAT a rude awakening.

Re: Elixir v1.4.0 released

#46

Post by ramchip »

brightball wrote: post #19
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.

Private (a.k.a. non-exported) functions affect how the compiler optimizes code, at least around inlining.

Re: Elixir v1.4.0 released

#47

Post by pmontra »

sch1zo wrote: post #34
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.

Am I misunderstanding this or what do you mean learn from ruby? In Ruby I can override private methods without a problem.

Ruby doesn't have private methods. You can always object.send(:method) and the only effect of the private keyword is to disable the object.method() syntactic sugar. No wonder that even methods marked as private can be redefined.

Re: Elixir v1.4.0 released

#48

Post by fooyc »

napsterbr wrote: post #21
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.

If you need raw computational speed you shouldn't be dealing with erlang / elixir anyway. Rust and go would be a proper comparison here

Anything that's good at handling a lot of I/O or a lot of concurrent processes tends to become CPU bound as more load is given to it.

It's not only about raw computational speed. Being good at concurrency means that you can handle more work, unless you consume too much CPU.

Re: Elixir v1.4.0 released

#49

Post by sotojuan »

xiaoma wrote: post #43
sotojuan wrote: post #10

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…

It's actually very much like the situation was with Rails a decade ago. Actually that was more extreme. Anybody remember all those "Rails vs _____" commercials from the Rails Envy people? https://www.youtube.com/watch?v=Y7Jte6NvLGU

Yes, Rails isn't innocent in this (most web things aren't). Just wanted to give an example.

Re: Elixir v1.4.0 released

#50

Post by brightball »

swsieber wrote: post #23
brightball wrote: post #19

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.

They seem quite useful. Mostly signaling that things should not be used. 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.

On a single code base, the most I've worked with at a time is 12.
Post reply on HN