Ten years without Elixir • Hacker News Board

Re: Ten years without Elixir

#141

Post by pmarreck » Sat, Jan 16, 2021, 9:32 PM UTC

jolux wrote: post #60

jFriedensreich wrote: post #51

As someone who came to erlang at least in part because i hated ruby (and also rails/phoenix like frameworks) i can partially sympathise. I would however put pipe operators clearly on the pro side of elixir and also add the string handling to that list (no pun intended). I am ultimately really happy about Elixir giving BEAM some new popularity in otherwise unreachable audiences, even though i had really hoped for some…

Do you have actual criticisms of LiveView as a technology or are you just upset about macros?

I think the criticism may be around "use", which calls that "magic" __using__ macro on the specified module, which will do who-knows-what.

Re: Ten years without Elixir

#142

Post by vendiddy » Sun, Jan 17, 2021, 2:09 PM UTC

jolux wrote: post #81

vendiddy wrote: post #73

Earlier quoted context omitted.

I love Elixir (former Ruby dev) but I do find many Ruby devs will turn to macros when regular functions will do. I haven't tried LiveView but it looks very interesting.

In this case I don't see how regular functions would do. It's a way of giving a module specific behavior in a way that fits in with the application structure Phoenix enforces. That aspect of it is very Railsy, but the way it's implemented is totally different. Elixir macros are much closer to Lisp macros than Ruby macros, because they are not object oriented. I personally find them much easier to read and understand…

I agree that Elixir macros are far easier to understand than Ruby macros since they are defined at compile time rather than runtime.

But I am against reaching for macros when the same can be accomplished using the basics: modules, functions, structs. I've seen various instances where a macro doesn't add much expressiveness over the plain old functional approach.

Granted there are many areas where macros are very powerful. Ecto is a perfect example of when macros make sense. Adds a lot of expressiveness to build queries which is worth the cost of macros.

Also should note that I love Elixir. We are using it in production to power all of our backend systems :)

Re: Ten years without Elixir

#143

Post by sodapopcan » Sun, Jan 17, 2021, 3:35 PM UTC

fulafel wrote: post #140

sodapopcan wrote: post #136

Earlier quoted context omitted.

I'm familiar with auto-currying from Haskell I've never worked seriously in a language that has it. But yes, that makes sense! I never thought about that. I'm a bit stuck on your Clojure example still, though. If a language doesn't have auto-currying (or even currying at all in Elixir's case), why does the argument order matter? Whether it's a List or a Map, what does it matter if it's passed first instead of last?

There is no general implicit currying. I suppose if we are exact with CS terminology, currying means converting to 1-argument functions, so that's out. But the threading macros do partial application in that they put the threaded-through value as an implicit argument. Look at the first examples in https://clojure.org/guides/threading_macros - the -> (thread-first) macro needs functions like assoc and update to take t…

I was more after an example of why argument order matters in currying collection functions, but I actually get it now :) With the object as the last parameter, you are able to create a function that, say, always reduces to a list with a specific function and takes an object. So yes, I understand peoples' objections now.

Re: Ten years without Elixir

#144

Post by rkangel » Thu, Jan 21, 2021, 11:18 AM UTC

swat535 wrote: post #92

jFriedensreich wrote: post #51

As someone who came to erlang at least in part because i hated ruby (and also rails/phoenix like frameworks) i can partially sympathise. I would however put pipe operators clearly on the pro side of elixir and also add the string handling to that list (no pun intended). I am ultimately really happy about Elixir giving BEAM some new popularity in otherwise unreachable audiences, even though i had really hoped for some…

What's the advantage that Elixir has over Erlang?

I would say there are two main differences and then some smaller more subjective ones. The main two:

Syntax - Elixir has a more familiar looking Ruby derived syntax, plus some little extras like the pipe operator. In practice, once you've used either Elixir or Erlang for a few hours the syntax difference isn't that important, you get used to it quickly. That first few hours is important though - if someone doesn't get through them they're not going to learn the language. Elixir makes that a bit easier, gives you one less thing to think about during early learning and helps adoption. There are some other niceties like the pipe operator and for comprehensions that can help organise code, but you could live without them.

Macros - Erlang has no capability for metaprogramming. Macros do need to be used sparingly and carefully as they can obscure what's going on (Erlang is very literal and that's a good thing). When used well they can be a great help at avoiding boilerplate. Elixir itself uses them for things like GenServers and supervisors. This does things like providing default child specs and allowing them to be overriden in the GenServer. Phoenix makes heavier use of them, mostly seamlessly (and it's a great benefit). The router is the only place where they're slightly confusing as the magically macros generate some extra helper functions. The mix tasks (mix phx.routes) show these generated function names, but it's not the same as having a definition in a file.

Other hand wavier things include better tooling (although a lot of the improvements are now present in Erlang tooling as well) and better documentation.