10 ms·

In case you are wondering what to use as your next programming language, please consider Elixir! It has a lot of advantages: - it is an easy to use, well-desi

• gamache 10y ago
  I love Elixir as much as the next guy, probably more, but I want to temper your enthusiasm a bit: > it is modern, with modern tooling around the language (e.g. mix, edeliver) Sort of. Mix is a nice package manager. Edeliver is a series of hacks on deliver, a five-year-old Capistrano clone. But don't expect Elixir to fit into 2015-class deployment systems just yet. > stack traces are clean, readable, and point you in the right direction most times Other times, the error happened in another process, all you see is a timeout, and it takes some spelunking. Not uncommon in my experience. But I'll also add a couple of points: - the docs system is fantastic, in particular the automatic generation of handsome docs websites, and the `doctest` system which allows example code in your docs to double as test code - I'm not sure there is anything better than supervisors for isolating and recovering from errors. Defensive programming is one thing, but sometimes your RAM stick gets hit by a cosmic ray. Shit happens; have a plan.
  • oomkiller 10y ago
    I am not sure how you define 2015-class, but building a release with distillery, and running docker build on a Dockerfile that copies the tarball (that includes everything needed to run your app (ERTS, app code, NIFs, etc)) makes a docker container that you can deploy as you'd expect. If you want to use clustering it's a bit more setup, but I was able to get a simple phoenix app running clustered on Google Container Engine (Kubernetes) in about 4-5 hours, starting with zero knowledge about Kubernetes or Elixir deployment. I pushed my code to github[1], and I did a talk on it at our local Elixir meetup[2]. Now that I have it figured out it's totally painless to upgrade, especially because of the Kubernetes tools. Simply make a new release, build a new container, push it to your docker registry, and then do a rolling update with kubernetes using the new version of the container. You can also add/remove scale on the fly, libcluster handles it all. [1]https://github.com/bbhoss/k8sexamplephx https://github.com/bbhoss/k8sexamplephx [2]https://www.youtube.com/watch?v=SNll1r6ZtO0&feature=youtu.be&t=4788 https://www.youtube.com/watch?v=SNll1r6ZtO0&feature=youtu.be...
    • gamache 10y ago
      It fits into industry-standard deployment systems, yes, but not without sacrificing some inherent benefits of the Erlang platform. In particular, hot upgrades and downgrades are no longer there, as Docker images try pretty hard to be immutable. Of course there are also the effects of flushing all server-local cache and/or memoization upon deploys too. Probably a bunch of other stuff I can't think of now also. So far I've preferred to stick to the Erlang way of doing things because it let me be laziest and it hasn't failed me, but someday I would like to see tools that allow the Erlang way and the e.g., K8s way to work together.
      • vertex-four 10y ago
        On the other hand, most people seem never to touch hot upgrades, even in Erlang, preferring the traditional rolling update across a cluster of machines. A lot of libraries aren't built for it either.
        • 10y ago
• lenkite 10y ago
  Does Elixir have step through debugging (breakpoints, etc) with accurate referral back to source code? Once one gets used to a modern, civilized debugging environment it is very difficult to go back into the wild.
  • djm_ 10y ago
    Yes, see iex (Elixir's interactive shell) and its pry function. If you're familiar with Ruby's pry or Python's pdb, it's very similar.
  • keyanp 10y ago
    The debugger is pretty good when using `iex`. However, you don't get "step through" debugging like you do with Python's `ipdb`, only breakpoints.
  • di4na 10y ago
    Yes the whole VM come with debugger, dynamic tracing and all by default. This is also distributed by default.
• bogomipz 10y ago
  I am curious if you or any of the other Elixirists(not sure what the community is called) spent time learning Erlang first or jumped right to Elixir? If yes would you recommend spending time with Erlang first or is not necessary? I guess I don't know if there is an Interop similar to Clojure and Java.
  • yellowapple 10y ago
    I learned at least the basics of Erlang first, mostly because I knew of Erlang's existence before I knew of Elixir's. I'd recommend it if only to help shake the "this feels like Ruby and I'm going to write my Elixir code like Ruby code" mentality. Also, I personally vote for the term for "Elixir user/enthusiast" to be "alchemist".
  • djm_ 10y ago
    Time with Erlang is not necessary beforehand but do go in with the knowledge that there is a lot of interop given you can call Erlang code in much the same way as Elixir code. Elixir made a decision early on to not deliberately wrap Erlang libraries that were perfectly sane as they stood. For example, to get a simple queue construct in Elixir you just call the Erlang queue module. Once you're up and running with Elixir then there is nothing stopping you delving deeper into Erlang and OTP.
    • bogomipz 10y ago
      Thanks I've been completely fascinated/mystified by Erlang and OTP so this might be good stepping stone with its own rewards. Cheers.
  • q1t 10y ago
    They call us alchemists!
    • bogomipz 10y ago
      Ah good to know. I like it!
• atombender 10y ago
  Elixir looks interesting, but coming from many years of using Ruby, another dynamically duck-typed language is the last thing I need, and (in my humble opinion!) the last thing I think anyone should need in this day and age. I have been using Go almost exclusively on the backend for the last 18 months or so, and it's a huge safety net. Go is nothing new, of course (it's basically Borland Pascal/Delphi -- which I also used for many years -- with GC), but it brings to the table a strictness that is very much needed (not to mention very good single-core performance). Almost all the problems I encounter in large-scale Ruby programs have to do with wrong types or wrong shapes of data being passed around. It's an antipattern, but we have a lot of code lying around that uses Ruby hashes (dictionaries) instead of classes, because it's easy to do; but even if you create classes to wrap you data and validate the type of every single piece of data you pass around, the surface area is too large to cover perfectly. Not to mention that Ruby suffers from its own icky form of null pointer problem, the nil value. And of course, static typing has many benefits -- not least allowing programmatic introspection (autocompletion, automatic refactoring etc.) in ways dynamic languages will never permit. I know Elixir mitigates the lack of static typing with pattern matching, guards and the possibility of using @spec together with Dialyzer, but I'm not at all convinced that this is sufficient.
  • yellowapple 10y ago
    "another dynamically duck-typed language" Elixir actually has things like behaviours and protocols instead of Ruby-style reliance on duck typing.
  • ch4s3 10y ago
    More importantly, a lot of this is diminished in importance in Elixir by supervisors. Its ok to just let code crash and reset in small chunks in Elixir. Code in Elixir should be structured to take advantage to the ability to crash and recover gracefully.
    • lobster_johnson 10y ago
      Well, Ruby will also crash on malformed data; exception handling makes it trivial to recover and continue. Using supervisors to recover by retrying allows you to correct for instability (network faults, oversaturation, locking and such) where a retry might actually fix things. What I am describing is something that cannot be retried in the first place; the next attempt would try to feed the exact same piece of wrongly-typed data back into the supervised process that would then fail again, and so on. Ruby doesn't have anything like OTP, but these are two different problem spaces. Elixir, as far as I can tell, is open to malformed data/types at runtime in exactly the same way that Ruby is.
• bjz_ 10y ago
  > stack traces are clean, readable, and point you in the right direction most times I really have not found this to be the case. You'll get obscure unmatched function clause errors coming from the opposite side of your program, that can eat up most of the day trying to track down, ending up having to carefully look at the function guards deep in library code to attempt to figure out where things broke. And not to mention the parse errors - completely unhelpful coming from languages like Elm and Rust. And then there is the huge overuse of metaprogramming - just use functions dammit! And how you have to go trawling through the source code to figure out what `__using__` is going to dump into your module. And cargo-culted Ruby syntax that's pretty hostile to FP...
• clishem 10y ago
  You forgot: - good marketing
  • moosingin3space 10y ago
    And that's not a bad thing -- it means the core team and users of the language are excited about it, which can be a good thing.
  • qaq 10y ago
    There are no big companies behind Elixir so the marketing is pretty much a community thing done by people who like the language.
    • cthalupa 10y ago
      Discord is using Elixir, and is pretty large. In another thread, their CTO claimed they have more users than Slack.
      • alxndr 10y ago
        There are big companies using Elixir; I think what qaq meant is that Elixir isn't itself developed by a big company.
• braveo 10y ago
  I'm curious about the performance of Elixir code compared to Erlang. I guess I'm what I'm really asking is how different is Elixir from Erlang in regards to the paradigm, and what performance costs does it pay for it?
  • ryeguy 10y ago
    There is no performance overhead, Elixir is equivalent to Erlang in that they both compile down to beam overhead.
    • braveo 10y ago
      This is the answer I was hoping I wouldn't get. I understand that it runs on BEAM, much like I understand that IronPython runs on the CLR. However, IronPython's performance is slower than C#'s performance due to the dynamic nature of the language, even with the special builtin support that MS built in. What I was asking is whether or not Elixir's performance characteristics were significantly different from Erlangs.
      • dalailambda 10y ago
        The semantics of Erlang and Elixir are very similar, as they're both dynamically typed functional languages, so the performance difference should be negligible.
        • braveo 10y ago
          alright, thanks :)
        • rvirding 10y ago
          They are not only similar they are in fact the same. Elixir compiles down to Erlang and the Elixir libraries are built using Erlang and OTP "underneath". Also the the BEAM, the Erlang VM, is designed to run Erlang so it is difficult to make an efficient implementation of a language with different semantics on top of it. It is truly Erlang all the way down.
• didibus 10y ago
  You talk a lot about how easy and approachable it is to an average programmer. Can you say anything to an experienced above average programmer as to why Elixir should be my next language? P.S.: If you're learning a new language, as a deliberate practice exercise, learning that language should be hard to you, or it won't be as effective in making you better.
  • Arcanum-XIII 10y ago
    First : functional programming — and strangely enough the data structure used for it (Clojure has collection, Lisp has, well, list, and Elixir is a mix a both for that) Second : actors and the various paradigm around it. Third : real (working) macro Fourth : Erlang/BEAM. Fifth : no parentheses discomfort, which could be a thing for you. No excuse to have fun. Sixth : the Erlang/Elixir tooling (dializer for static check, mix, exrm, distillery, edeliver... and you even have a type system with typespec) This is not a hard language to get. That's not it's purpose. It's practical if you want to adhere to the actor system, functional everywhere and so on.
    • didibus 10y ago
      What would be the advantages from me just going straight into Erlang? I've got experience with Clojure and F#/OCAML, but I've never used the actor model, and i'd like to have a BEAM VM language under my belt. I can't choose between Erlang or Elixir or LFE.