5 ms·
Elixir Anti-Patterns
- mervz 2y agoElixir is one language I REALLY want to use as the solo developer working on internal infrastructure tools; but I'm very hesitant as I don't want to be cruel to the person who eventually replaces me and has to maintain these applications written in this seemingly (awesome) niche language. Instead, I'm stuck writing applications in Go which is a language I absolutely despise but can't deny it's ability to get shit done regardless of the insane amount of boilerplate code I have to write. Any predictions on whether Elixir will eventually gain more traction? The language and platform are rock solid and it's the best developer experience I've encountered. Phoenix is by far my favorite web framework and just feels very intuitive and complete. The lack of a good IDE is one huge pain point that I can't seem to overcome (I don't care how much people praise it, I know it's the best but VSCode is awful for Elixir development). I just wish this language was more popular because it deserves to be!
- abadpoli 2y agoPart of this story is a self fulfilling prophecy. If devs like you avoid using Elixir because you’re afraid it isn’t popular enough, then it isn’t going to become more popular!
- mark38848 2y agoWhy wouldn't you feel bad for the person having to write Go after you? Makes no sense to me
- ch4s3 2y agoI assure you that the Go evangelists before you(in general if not here specifically) had no such compunction about imposing that language on whoever was unlucky enough to inherit it.
- ikety 2y agoTrue, but you kind of get to introduce what you want as long as it's popular and well backed. Even if I know a tool or language is better suited for a task, I always prioritize my employer's ability to maintain that project over time. That usually means using similar technologies, or otherwise popular, and well backed technologies. Go has that in abundance over Elixir. For any personal project I'd take Elixir the vast majority of the time.
- ch4s3 2y agoWhat I mean is that at some point Go was Rob Pike’s side project inside of Google and even Google wasn’t really using it. Back then it was an even more painful language to use. People outside of Google who latched on were imposing that choice on a lot of future maintainers.
- gregors 2y agoExtremely well said. There are reasons gigantic corporations like Microsoft and Google spend all that money convincing you to use their new creation.
- sbuttgereit 2y agoAs already mentioned: it will only gain traction if/when less conservative developers and managers decide to use it. If everyone plays it safe, then no: it doesn't stand a chance because Java, Go, JavaScript, Python (etc) already exist. But I would argue the decision to adopt Elixir isn't really as simple as a "this language" or "that language". The most essential decision, I would suggest, is about Erlang... not so much the language as much as the virtual machine and OTP. If the problem you want to solve is well solved by the BEAM/OTP, then you start to look at the languages you might use with the BEAM/OTP. I think BEAM/OTP is underappreciated for many use cases and that are worth exploring; this broadens if you consider BEAM/OTP augmented with more performant programs built with a language like Rust/Zig/C/C++. But if everyone plays the conservative game and doesn't see the risk/reward payoff with BEAM/OTP favorably... then it will be the same old boring players with only the ocassional influence from the sidelines.
- gregors 2y agoI know a BUNCH of elixir devs that would love to pick up an Elixir project that needs a new lead....just saying. There's plenty of talent looking at the moment.
- neoecos 2y agoI'm hiring for this, Fintech project, 100% Elixir + Phoenix + LiveView. Email at bio
- josefrichter 2y agoMaybe more "traction" is not that important, in the end? BEAM has been around for decades and has proven its worth. Elixir has been around for quite some time too, is super stable and reliable, has a pretty decent user base, real-world applications, ecosystem, etc. In many cases, it's arguably the best tool for the job. And it's not like some critical piece of puzzle is missing. So it may stay kinda niche forever because people who fully understand the problem and fully realize how to solve it will also always be niche.
- mtndew4brkfst 2y agoAny predictions on whether Elixir will eventually gain more traction? I have 10 years with the language this year, much of it as a professional fulltime focus in senior IC roles. I would be shocked to my toes if there was ever going to be even 10 times more active Elixir devs than there are today, let alone more extreme growth. And I think that hypothetical plateau is an appropriate outcome commensurate with its ecosystem's breadth, applicability and quality today. Many libraries have single or absentee authors, even some you would assume were critical to the community, and major vendors in many verticals don't give us any thought when providing SDKs/integrations. Elixir seemingly doesn't have any major backing or adoption from large polyglot orgs or top FortuneN groups. We have failed to reach critical mass for broad mindshare, IMO. I have no personal plans to write net-new Elixir that I wasn't explicitly hired to work on in that specific stack.
- chuckadams 2y ago> Any predictions on whether Elixir will eventually gain more traction? I don’t know about Elixir, but Gleam looks promising. Even less IDE support than Elixir right now though.
- mjoin 2y agoUnpopular opinion given all the craze around Elixir these days. I find the syntax extremely verbose and hard to read compared to e.g. Python. I was told great things about it by engineers I really respect. But each time I start reading Elixir code bases to get a good look at what an actual Elixir project looks like, I find the code hard to read and understand. Is it just me?
- lytedev 2y agoI felt the same way at first coming mostly from JS. I think it's different enough that you need it to become familiar before it feels as comfortable. That said, I don't think it's as easy to read as Python, but the perceived verbosity and reading difficulty definitely goes down with familiarity.
- natrys 2y agoTbh, I find well written Elixir to be easier to read than Python. But that's mostly down to functional vs imperative which is subjective/cultural. The same code using higher order functions and pipes that feels much simpler to me would likely be unpalatable to most Go programmer I know, and maybe a lot of Python programmers too (tbf, I can't stand the vast majority of Go code I have seen either). Part of the verbosity is because Elixir is kind of a simple language (if you disregard the OTP stuff) and doesn't have a lot of sugar - ultimately it's just functions. Whatever else sugar is there is to nudge you towards a somewhat opinionated aesthete. In this specific regard, it's not unlike Go or Smalltalk (even if in any other way they are very different otherwise). I think the stylistic variance in how different people write Elixir is pretty low compared to how people write Perl/PHP/Ruby/Python, which is probably why reading difficulty quickly goes down with some familiarity. Other part of verbosity is probably because culturally Elixir is kind of explicit. For example Phoenix is very convention heavy, but it's still low on framework magic. It's cool that Elixir (and Julia) has macros and that's good for library and framework authors to contain verbosity without sacrificing much of the explicitness. But as an application developer I very rarely need to reach for them either? Perhaps that's due to simplicity of language and synergy between data structure and standard library. Though based on usage there are probably some areas where I would have preferred more sugar. For example, you just end up doing a lot of deconstructing/pattern-matching Maps. Every time I do `%{var1: var1, var2: var2} = map` I wonder if it would really be bad to have `{var1, var2} = map` like Javascript? It's not a very big deal though. Also not to be a naysayer, there is a chance that the good feeling people have about Elixir is because they basically use it in the problem domain where the language and the runtime (and Actor Model) is an exceptionally good fit for. I mean web and network stuff is already large part of what people do, so that's not much of a con? Nevertheless would I pick Elixir for my next GUI or CLI program? I doubt it.
- Terr_ 2y ago> Complex else clauses in with This has proven controversial, but sometimes the Else behavior is very sensitive to which of the With expressions failed (especially for better logging) and I maintain that the least terrible approach involves augmenting the With clauses using atoms to identify each expression when it fails, ex: For example: with {_, {:ok, key} } <- {:phase_key, get_key() }, {_, {:ok, door}} <- {:phase_unlock, unlock(door) }, {_, %Thingy{} } <- {:phase_thingy, fetch_thingy(door)}, {_, %Widget{} } <- {:phase_widget, fetch_widget(door)} do else {:phase_key, {:error, _msg} = err} -> # I can tell the key was missing, rather than the lock broke {:phase_unlock, {:error, _msg} = err} -> # I can tell the lock broke, rather than missing a key {:phase_thingy, nil } -> # I can tell this nil value is a missing thingy, not a widget {:phase_widget, nil } -> # I can tell this nil value is a missing widget, not a thingy end As a big bonus, when something crazy-unexpected is emitted to cause a WithClauseError--like "hello world"--you have a much better chance of quickly diagnosing what happened from log messages, instead of inspecting a dozen different logical branching or trying to blindly repro it. Pre-buttals: "Just rewrite those 4 functions to return better somehow" -> No, that's not always practical or even possible. In the above example, the signatures of some of these functions are already perfectly fine on their own. The ambiguity comes when they get used near others in different ways, and trying to assign globally unique features to match on is a bad idea. "Create 4 private functions to wrap things" -> Ugh, now the person reading the code has an even harder time, since they need to refer to functions elsewhere in the file, any of which might be hiding unexpected bonus behavior. Those 4 private functions might not even be useful in other with-statements in the same module, causing you to make even more private functions... and all of it still falls apart the moment your Else logging/cleanup needs to record or revert something from a prior (successful) step.
- Terr_ 2y agoAnti-pattern: Overuse and misuse of macros. (Or perhaps not a "pattern", since the manifestations are so varied?) For non-Elixir folks, imagine something that looks like a regular function-call where expressions are evaluated and the results are passed in... but in reality all arguments are symbolic inputs to something that emits new code. For example, you might see this unassuming line in your editor: describe_combo(a(foo),b(bar)) But what might actually be compiled is: # What might actually get compiled # Runtime results like "a(1)+b(2)=3" "a(" <> to_string(foo) <> ")+b(" <> to_string(bar) <> ")=" to_string(a(foo)+b(bar)) And if someone in your codebase is an evil misanthrope: foo = "haha I changed your local variable" IO.puts("surprise, suckers") # Prints to console kick_puppies() Macros are actually part of the core DNA of the language and underpin how some of its syntax works... but with great power comes great potential for WTF.
- josevalim 2y agoElixir macros are hygienic, so you need to be more explicit if you want to override variables as above. You also need to require macros before using them, but once you do you can kick all the puppies! There is also a guide on meta-programming anti patterns: https://hexdocs.pm/elixir/macro-anti-patterns.html https://hexdocs.pm/elixir/macro-anti-patterns.html (and unnecessary use is one of them).
- fouc 2y agoJose Valim gave an overview of this in last month's ElixirEU Conf https://www.youtube.com/watch?v=agkXUp0hCW8 https://www.youtube.com/watch?v=agkXUp0hCW8
- deleted 2y ago[deleted]