#elixir-lang

/

      • eddd has quit
      • lmoura has quit
      • jesseherrick joined the channel
      • k-dawg joined the channel
      • jesseherrick has quit
      • paulcsmith has quit
      • jher has quit
      • Guest83376 joined the channel
      • brianhicks joined the channel
      • dnorris joined the channel
      • eddd joined the channel
      • yt__ joined the channel
      • d1plo1d joined the channel
      • gtcarlos has quit
      • drewolson has quit
      • gtcarlos joined the channel
      • maz-dev joined the channel
      • hassox has quit
      • lmoura joined the channel
      • dnorris has quit
      • Swappticon joined the channel
      • hassox joined the channel
      • maz-dev has quit
      • tristanp_ joined the channel
      • tristanp has quit
      • smoon joined the channel
      • williamdunne joined the channel
      • brweber2 joined the channel
      • smoon has quit
      • mphhh joined the channel
      • rossfu joined the channel
      • brianhicks joined the channel
      • mfg joined the channel
      • sevenseacat joined the channel
      • lessless joined the channel
      • meatherly joined the channel
      • joseluis_torres joined the channel
      • d1plo1d has quit
      • joseluis_torres has quit
      • d1plo1d joined the channel
      • d1plo1d has quit
      • rossfu has quit
      • PhatLe joined the channel
      • Zepplock
        So I'm looking at some existing Elixir code and I see more and more cases like this:
      • where same function accepts {:ok, ..} and {:error, ...}
      • I guess this an erlang way of doing things
      • is it preferred to say throwing an exception?
      • alisdair
        Zepplock: you mean produces?
      • Zepplock
        no, accepts
      • alisdair
        oh
      • i think that is more of an elixir thing
      • you rarely see that in erlang
      • Zepplock
        I find it a bit counterprodcutive
      • alisdair
        but it is a way to do something similar to option types from a language like scala
      • Swappticon
        Throwing an exception in Erlang/Elixir is only for very exceptional circumstances
      • Zepplock
        first I get a lot of boilerplace code: defp extract_token({:error, message}), do: {:error, message}
      • Swappticon
        It shouldn't be used for control flow.
      • Zepplock
        I heard that before, not sure if what I see/do is better though
      • so problem 1: meaningless code, see above
      • problem 2, you can't use |> with a code like that
      • Swappticon
        I'm not sure I understand your question
      • Zepplock
        is there a good codebase where I can find examples?
      • swappticon: what exactly? problem 1 or 2
      • Swappticon
        Good examples of Elixir code in general?
      • Zepplock
        no
      • an example where control flow is complex (like in https://github.com/bitpay/elixir-client/blob/ma...)
      • but it's well written
      • alisdair
        it's a technique that allows you to delay handling errors until necessary. so instead of checking for errors at every possible site you just propogate them upwards until you need to check
      • Zepplock
        I don't like a code like that, where every function call has a twin
      • alisdair
        it shouldn't always be used but it's useful when you have a complex processing chain with many possible errors all handled in a similar way
      • Swappticon
        That's just basic pattern matching. That is how a lot of Elixir code is written
      • Zepplock
        I guess I just can't wrap my head around it
      • I mean I understand, but maybe there's a more optimal way of handling errors in a complex processing chain
      • for example
      • mitchellhenke joined the channel
      • I can rewrite that code with try/catch style and remove 50% of code
      • mitchellhenke has quit
      • engwan joined the channel
      • is having 50% of boilerplate, meaningless code better than using try/catch?
      • is try/catch super expensive?
      • alisdair
        50% of the function heads maybe, but the try catch code requires just as much boilerplate
      • Zepplock
        from performance point of view?
      • alisdair
        try/catch isn't expensive from a performance standpoint but does prevent tail call elimination which is a concern in recursive operations
      • Zepplock
        not really, 1 try/catch, and throw in place of every {:error, ...}
      • codestorm has quit
      • tuningmind joined the channel
      • Swappticon
        You could use control structures, but I think control structures are discouraged in Elixir when you could accomplish the same thing with pattern matching
      • alisdair
        i don't see how that is an improvement over def foo({:error, E}), do: {:error, E}
      • Zepplock
        maybe my problem is coming from Ruby world where everything is as DRY as possible
      • even though I used to scold people for using exception in the control flow when I did hardcore C++
      • Swappticon
        The difference is that Elixir code tries to be declarative and not imperative. That is why pattern matching is recommended
      • Zepplock
      • is that considered good Elixir code?
      • I dont like it either
      • looks like a callback hell from JavaScript world
      • devbug joined the channel
      • maybe it's just a case of Monday. Mondays are hard ;)
      • alisdair
        that code has style issues but i don't think it's particularly bad. without knowing what it's trying to accomplish it's hard to say whether it's good or not
      • codestorm joined the channel
      • asebastian has quit
      • clarkkampfe
        When I'm looking for examples of good Elixir, I usually go inspect the language source. It's pretty tidy.
      • Zepplock
        so is it advisable to return {:ok,..} or {:error...} from functions?
      • Swappticon
        Yup. That is very common
      • davidmn has quit
      • avahey has quit
      • alisdair
        it depends. if errors are exceptional you should probably just throw an error on error
      • if errors are routine you should tag them in the return probably
      • clarkkampfe
      • tristan__
        my errors are always exceptional
      • alisdair
        it also depends on the purpose of the function. most things that manipulate data types should probably return bare datatypes
      • so you can call them inline and not have to unwrap them before passing them to a function
      • greengriminal has quit
      • alexkrus joined the channel
      • Zepplock
        ok, let's say you need to write a set of functions that validate stuff. So you have v1, v2, v3 and they work on a %{..}
      • keroro520 joined the channel
      • mitchellhenke joined the channel
      • would you make each return {:ok..}/{:error..} or return %{...} if everything is fine and throw if validation fails?
      • alisdair
        it depends
      • Zepplock
        by %{...} I mean a data structure, like a database record
      • that I get ;)
      • alisdair
        if it was part of an application probably the former, if it were part of a library i expect others to use probably the latter
      • Zepplock
        but it seems that those 2 approaches are fundamentally different
      • ok
      • what if I say that it's a code of a Model (in Model/View/Controller world)
      • brweber2 has quit
      • alisdair
        well i think for internal private use you probably want a convenient api, whereas for external use you probably want a flexible interface
      • Zepplock
        is Model a library or an application?
      • brweber2 joined the channel
      • alisdair
        part of an application
      • Zepplock
        ok, I think I understand what you are suggesting
      • greengriminal joined the channel
      • paulcsmith joined the channel
      • engwan has quit
      • thank you
      • seank_ has quit
      • seank_ joined the channel
      • paulcsmith has quit
      • greengriminal has quit
      • meatherly has quit
      • PhatLe has quit
      • seank_ has quit
      • greengriminal joined the channel
      • lbotos
        Hey all, new to elixir. Not really sure what's going on here {x, ^x} = {2, 1} Can anyone clarify?
      • Pinning is confusing me.
      • Radar
        Doesn't evaluate in iex.
      • ** (CompileError) iex:1: unbound variable ^x
      • PhatLe joined the channel
      • lbotos
        Radar: my bad, forgot x = 1