Reasons to use Phoenix instead of Rails

Re:Reasons to use Phoenix instead of Rails by cutler on Sunday November 26, 2017 @02:23PM (#15782497)

One reason not to use Elixir is the absence of vectors/arrays. Yes, you can import them from Erlang but they ain't pretty. Elixirists try to pretend that lists and tuples are all you need but Elixir's lists are Lispy lists, not the Python variety. It's one of these small print things you only discover after spending time with Elixir but it can be a deal-breaker. Ask on the Elixir lists and you'll get some very defensive responses which basically add-up to vectors/arrays being difficult to optimise in a dynamic functional language. String processing is also not quite as straightforward as in Ruby and Python due to how Erlang/Elixir uses binary representation.

[ Parent | on HN ]

Re:Reasons to use Phoenix instead of Rails by tbrooks on Sunday November 26, 2017 @03:21PM (#15782775)

You've brought this up before. [0]

[0] https://news.ycombinator.com/item?id=12013088

[ Parent | on HN ]

Re:Reasons to use Phoenix instead of Rails by tomcam on Monday November 27, 2017 @10:58AM (#15788274)

Is there a limit to the number of times one can state the same opinion on HN?

[ Parent | on HN ]

Re:Reasons to use Phoenix instead of Rails by paulcsmith on Sunday November 26, 2017 @02:26PM (#15782507)

Can you explain a bit more what you mean? What advantages do "Python variety" lists give you over what Elixir does with lists and tuples?

[ Parent | on HN ]

Re:Reasons to use Phoenix instead of Rails by cutler on Sunday November 26, 2017 @02:38PM (#15782562)

Python's lists are really arrays/vectors as in Ruby ie. well-optimised for index-based access. Erlang/Elixir lists are linked lists which are more optimised for appends than index-based access though you can achieve the same with Enum.at(list, index). With small lists/arrays the difference isn't noticeable but it will affect performance with large lists.

[ Parent | on HN ]

Re:Reasons to use Phoenix instead of Rails by dnautics on Sunday November 26, 2017 @03:29PM (#15782813)

If we're being honest, Python lists aren't arrays either, they are arrays of pointers which need to be unboxed before using. If you really really need array performance, then drop down to c, or use a language like Julia. Lists give you the ability to quickly pass these structures as immutable objects, which in turn, you want because of safety guarantees in concurrent environments.

[ Parent | on HN ]

Re:Reasons to use Phoenix instead of Rails by elcritch on Sunday November 26, 2017 @03:47PM (#15782894)

The lack of true arrays or vectors haven’t been an issue for me across a couple of domains. Of course maps can always be used as indexed based lookups for mid-sized problems (similar to lua’s combined array/map type).

What problems have you been facing where it’s an issue? It’d be nice to know to avoid said problems upfront.

[ Parent | on HN ]

Re:Reasons to use Phoenix instead of Rails by bousaid on Sunday November 26, 2017 @03:15PM (#15782743)

Arrays and vectors are different. I’d suggest adhering to C-like conventions of data structures.

[ Parent | on HN ]

Re:Reasons to use Phoenix instead of Rails by jondubois on Sunday November 26, 2017 @05:18PM (#15783382)

I never bought into the pure functional programming hype. Most programs are made up of many functions and as the program gets more complex, the code paths keep getting longer... If you force everything to always be passed by value and returned by value (never by reference) it's clear that the costs of constantly cloning all these objects would quickly add up.

The problem with pure functional programming is that it prevents the developer from writing well optimized code.

State change side effects might be dangerous, but they're also a really good way to boost performance and sometimes they're totally worth it.

[ Parent | on HN ]

Re:Reasons to use Phoenix instead of Rails by ramchip on Sunday November 26, 2017 @06:59PM (#15783815)

> If you force everything to always be passed by value and returned by value (never by reference) it's clear that the costs of constantly cloning all these objects would quickly add up.

That’s not what happens. See: http://erlang.org/pipermail/erlang-questions/2013-March/0727...

“Pass by value does NOT imply copying and never has; copying is only required for mutable data structures, and Erlang hasn't any.”

[ Parent | on HN ]

Re:Reasons to use Phoenix instead of Rails by cutler on Monday November 27, 2017 @06:08AM (#15786461)

See Rich Hickey's description of structural sharing in Clojure. Persistent data structures are not simple copies.

[ Parent | on HN ]