28 ms·
Elixir at PagerDuty
- anthonybullard 8y agoI'd love to hear more about your troubles with Scala, and any examples of "clean code being hard to write". Do you think this had more to do with a lack of experience with strongly typed functional languages, or more to do with Scala's mixed paradigm? Also, thanks for sharing your story. Elixir is a great language and I love seeing it being adopted more and more everyday.
- justinator 8y ago(backend of Victorops is in Scala)
- romanhn 8y agoDefinitely not the lack of experience, there was plenty of in-house Scala experience. I'm not the author, but he has indeed written about his experiences with Scala on his personal blog: http://evrl.com/programming/scala/2017/04/04/scala-part-ii.html http://evrl.com/programming/scala/2017/04/04/scala-part-ii.h...
- mopierotti 8y agoI wish he would have gone further into detail on why "stuff like Scalaz has no place outside academia". While I understand there's a bit of mental overhead, I've found there to be much real world utility in using that genre of libraries/patterns in production. It's also interesting that he wants the ability to "run your tests for the intermediate refactoring steps that wouldn’t typecheck and then let you fix up things later."-- I'm not sure what it means to want to run code with ambiguous types in a type aware language like Scala. Type information is deeply involved in runtime program behavior. (E.g pattern matching on types, resolving typeclass instances) I certainly agree that nontrivial sbt work is rough.
- jvican 8y agoI don't know what he meant by that either, but it's important to mention that `Scala != Scalaz` and that sbt is not the only build tool used in the community (and it's certainly not built by academics!).
- gamache 8y agoI'm not from PagerDuty, but I also moved to Elixir after some years working in a hybrid Ruby + Scala shop. I concur with the author's experience that writing clean and maintainable Scala code is hard. A few reasons: * Haskell influence on the language, especially early on, encouraged the omission of dots and parentheses wherever possible. Just about every piece of sample code was written as an undifferentiated stream of tokens. There is a mental burden. * Haskell influence on the community encourages category theory solutions to all problems. This harms interop with Java libraries, in addition to requiring a number of concepts that are safely ignored in many/most other languages. * Scala's rich OO system (classes, interfaces, traits, singletons, case classes, implicits, etc) results in frequent design paralysis, not to mention taking a while to learn. Elixir suffers from none of these problems, while retaining some of the things that made Scala a pleasure to use, notably the actor system of concurrency and the use of immutable data structures.
- jvican 8y agoI work for the Scala Center and I'd like to comment on some of the points you make to hopefully explain how I see things from my side. You can expect my opinion to be biased but I'll try to stick to the facts. > Haskell influence on the language, especially early on, encouraged the omission of dots and parentheses wherever possible. This is considered an anti-pattern in the Scala community. The last library that used this at large scala was sbt, Scala's build tool, and now everyone discourages the use of infix operators. > Haskell influence on the community encourages category theory solutions to all problems. This is simply not true. First, there is no Haskell influence on the language. Scala is a functional programming language, all similarities between the two are just fundamental to how their type systems work and the foundations of the paradigm. Second, I contest heavily that the Community encourages category theory to solve all the problems. There are many subcommunities in Scala and many styles, but if you talked to some Scala developers nobody would agree that category theory should be applied to all code. In fact, most people don't. They just use Scala because it's a better Java that boosts their productivity. > Scala's rich OO system (classes, interfaces, traits, singletons, case classes, implicits, etc) results in frequent design paralysis, not to mention taking a while to learn. Absolutely agree that for someone not experienced, it may be difficult to know what's the best way to design libraries (this is more of a problem with libraries than applications). This is a big problem of Scala that I think we're solving by making the language more opinionated and being more open about what's encouraged and discouraged. If you ask for my opinion, I think we also need to make a better job at communicating all this knowledge that advanced Scala developers learn but that is usually kept to closed circles.
- nemothekid 8y agoI'm pretty sure, as far as type systems go, Elixir is strongly typed as well as fairly functional (It's built on BEAM after all). I think it has to do more with the latter. To me, Scala is too powerful - it rivals C++ in complexity, despite being half it's age. It almost feels like every Scala codebase is written in a different language, and I always felt I spent more time parsing Scala than understanding the code. It's a powerful language to write, but hard to read - almost the complete polar opposite of Go. As a result it can be very hard to bring new engineers up to scala, and even engineers that know Scala have to learn "your flavor" of Scala.
- gamache 8y agoElixir is dynamically typed, just like Erlang and the BEAM. Strong typing is a most requested feature from outside the community, seldom from inside. (EDIT correct, strong typing is not static typing. Does anyone make weakly typed languages anymore?)
- nemothekid 8y agoAccording to wikipedia, Erlang/Elixir is strongly typed. I guess you and the other poster mean static typing?
- Thaxll 8y agohttps://elixir-lang.org/getting-started/typespecs-and-behaviours.html https://elixir-lang.org/getting-started/typespecs-and-behavi... Elixir is a dynamically typed language, so all types in Elixir are inferred by the runtime.
- dudul 8y agoYou may be confusing strongly and statically typed.
- rpeden 8y agoThere's no reason a language can't be both strongly and dynamically typed (like Elixir or Python) or statically and weakly typed (like C). :)
- everdev 8y ago> Elixir has been mostly selling itself: it works, it sits on a rock-solid platform, code is very understandable as the community has a healthy aversion towards the sort of “magic” that makes Rails tick, and it’s quite simple to pick up as it has a small surface area I was a huge Rails fan back in '07 and built a number of apps with it successfully, but I can't help feel like it's transition to a legacy framework has already begun. While Rails was never top in the performance category, languages are catching up in tooling and readability. So, now you can get performance and a great developer experience with multiple other languages like Elixir, Crystal, Go and more.
- cutler 8y agoHow can you compare the overall developer experience of Crystal, which isn't even 1.0 yet and has very few libraries, with the mature ecosystem of Rails?
- freedomben 8y agoNot OP, and not Crystal, but comparing Phoenix ecosystem with Rails is pretty doable. There are a lot of packages available. Obviously not as much as on rubygems, but one can get a pretty good feel for the overall developer experience. My enjoyment of rails isn't really about the wide array of gems available anyway. It's the paradigms and community standards.
- joelbluminator 8y agoRails is also very powerful because of hundreds of thousands of answers on Stackoverflow and countless blogs. It's not easy to reach that level.
- everdev 8y agoAnother reason why JavaScript is unfortunately so popular.
- 8y ago
- jxub 8y agoMy impression about the Elixir/Erlang so far has been the same. > Elixir comes with one of the nicest and most helpful communities around Using Elixir, it's easy to write gorgeous code, with a language that for the most part is really minimalist, and you get to play with the great piece of software that OTP is without all the warts of Erlang (which is mostly the developer experience). The BEAM community is fantastic and really supportive (disclaimer: I'm a GSoC student working for them on making Elixir bindings for Barrel, a replicated document database). Maybe we could think that it's best in terms of the character of the community if Elixir stays small, however Rust community seems a great example of something bigger to follow that hasn't evolved into a soulless graveyard of enterprise code scattered on the githubs and maven centrals of the world. There has to be a way between hand-rolled craft parsers you write with a beard and an IPA in hand and another AbstractObservableContainer written by Dilbert that doesn't compromise the ecosystem or contort it in any funny way.
- gamache 8y agoRust is a community of very nice and helpful people, much like Elixir but with more money behind it. However, I certainly enjoy Elixir's unwillingness to break working code with every release, or to force users to build against nightly releases just to use any features from the last year. Rust is improving in this regard, but isn't quite there yet.
- qaq 8y agoThere is good interop story for Elixir/Rust. I would not be so sure about money bit either.
- gamache 8y agoThere's a fine interop story, I've used Rustler before. The problem is when Rust nightly is sufficiently broken that even the auto-generated Rustler boilerplate won't compile. :)
- skrebbel 8y agoJust some random background for those reading about why Erlang/Elixir<->Rust interop is A Big Thing. The whole point of Erlang and Elixir is robustness in the face of high concurrency. All other design choices (eg functional programming, immutable data), follow from that goal. Core is that if one green thread ("process" in Erl/Ex lingo) crashes for whatever reason, the rest keep on running. Interop with native code is the sole exception here, which makes interop very scary. If a C function that's called into from Erl/Ex crashes, the entire program crashes. Boom, gone. Sure that holds for most other languages too, but Erlang/Elixir people get extra nervous because they're more accustomed to thinking about error scenarios and because they don't always have the same seven restart/recover layers outside the VM process that good devopsers wrap eg Node processes with because hey, no need, we have Erlang, we never crash. As a result, the idea of a technology that allows writing native code that has a tremendously small likelihood of crashing is very appealing. Until recently, no such technology was available but Rust changed that. Rust allows writing native functions that can be called from Erlang/Elixir with much fewer worries than C/C++ native extensions ever did, because of all the safety guarantees provided by the compiler. This is a big thing and I hope that as the interop story improves, it means that Erlang/Elixir will in practice become much faster because more libraries will be rewritten in native code.
- brightball 8y agoGreat hearing more and more Elixir adoption stories from well known companies. The quote that resonates... > ...some of us are secretly hoping that one day, we’ll only have to deal with Elixir code
- mercer 8y agoI've been lucky that I could choose my stack on a few projects, but I also hope Elixir will keep getting more popular so that I can use it for the more common contractor-type things I get offered.
- gandreani 8y agoThank you for sharing your experience! New languages is one of the "fun" parts of programming. Except at work. There are legitimate problems of legibility, maintainability, and training when introducing new stuff into the stack. Then there's the balance that we have to strike with re-writing old with new. How much do we gain with the new vs how much time is it gonna cost? Lately, these have been the things I worry about instead of algorithm design or product design. Precisely the things we don't get taught in school or get interviewed for
- brightball 8y agoTrue. In my experience that largely depends on the environment. In Java or .NET shops, there is a significant investment in the surrounding infrastructure where the code is deployed. Has a huge impact in cost of switching. That's before even factoring in some of the inside baseball related to "discounts" on products like SQL Server if you have a certain number of employees with Microsoft certs. For just about everything else though...it's not nearly as much of a headache.
- deleted 8y ago[deleted]
- gandreani 8y agoOh man. Those discounts sounds like such a headache. It's hard enough considering the asks for one department already... Environment is definitely the key. We don't use either of those languages but we do run our site on a dozen or so servers. There's a fair bit of coupling that can eventually add up when you run the same apps on the same servers for years
- enraged_camel 8y agoElixir is amazing. It is everything I want in a programming language: functional, fast, reliable and elegant. I desperately want it to become more popular. To this end, I started writing a book that teaches Elixir (Phoenix) in combination with Vue.js. It's still in the early stages, but the thing I realized is that even writing the book is fun! This was very surprising to me because I typically don't find writing technical documentation/tutorials pleasant. Anyway, if you're on the fence about Elixir, definitely check it out - especially if you're coming from a Rails background!
- jacquesm 8y agoLooking forward to your book!
- cube2222 8y agoHow is the library ecosystem with elixir? Currently I'm usually using Go where I have a library for anything and I'm quite apprehensive to start using elixir if there's a lack of libraries.
- cnnrjcbsn 8y agoIt's pretty solid. You may have to roll something yourself for really esoteric APIs, but pretty much everything you probably want to use is supported already
- deleted 8y ago[deleted]
- qaq 8y agoIt's decent plus you can use all the Erlang libs. Unlike Go Elixir has very nice package manager hex :)
- pera 8y agoYou can search for anything you need on Hex: https://hex.pm/ https://hex.pm/
- dmlittle 8y agoI love Elixir but being completely honest the ecosystem is sometimes lacking. That isn't to say that you can't do things but rather sometimes you need to rollout your own version of something. For example, Redix refused to support SSL because Redis didn't support it natively[1] even though Redis providers started wrapping Redis with SSL proxies (the maintainer has since then reconsidered and agreed to add SSL support). We also couldn't find a decent library for payload validation. There are Ecto changesets but these are things you check right before saving to a DB after you might have done a lot of work already. Sometimes there are split clients for what I wish had a community recommended or be in the std lib. For example HTTPotion[2] vs HTTPoison[3] (names are _super_ similar and sometimes confusing). [1] https://github.com/whatyouhide/redix/issues/77 https://github.com/whatyouhide/redix/issues/77 [2] https://github.com/myfreeweb/httpotion https://github.com/myfreeweb/httpotion [3] https://github.com/edgurgel/httpoison https://github.com/edgurgel/httpoison
- Touche 8y agoI wonder about a language like Elixir in the age of serverless. Erlang will always be great at the use-case it was originally written for (and what Whats App uses it for), but that's not the scale that most startups operate in. With serverless the advantages that Erlang has don't matter much, since the process doesn't live along to utilize them. Instead the bottleneck is cold start times. So these types of languages (including Java) that are meant to start and stay running for a long time aren't a great fit. Go, Rust, possibly Pony, are better fits. Even Node isn't a superb choice, cold starts can be slow because of loading so many files.
- qaq 8y agoYou do realize that outside of cloud providers hype "serverless" is a tiny fraction of cloud use let alone overall use.
- Touche 8y agoSome times hype is warranted. Get passed it and look at the actual technology and its value. If you are building a website in 2018 you are doing yourself a disservice manually managing servers.
- qaq 8y agoat our scale if we used "serverless" our AWS bill would go from several mil a month to 20+ mil. plus
- peterwwillis 8y agoAs someone who has managed large clusters of Erlang applications, I have to say I am 100% convinced that the language you pick, no matter how amazing its design principles, has no bearing on how well the application runs. If you work for a telecom and you're actually trying to meet a nine-nines SLA, you can do it with Erlang. But if you're a start-up throwing together some random distributed app on a small budget, nine-nines probably isn't your goal, and so your application won't be nearly as stable.
- sb8244 8y agoTotally. Uptime & stability is a mentality and a feature, never a free ride! At the same time, having a solid foundation and a community that knows how to take it to rock solid stability is valuable.
- mmartinson 8y agoComing to Elixir/Erlang from Ruby, there is a whole new world of thing to break and horrible mistakes you can make. Fortunately, the language/VM also makes it a whole lot easier to fix the horrible new mistakes once you discover that you've made them.
- vikingcaffiene 8y agoI worked on Elixir at my last job and it left quite an impression. At my current role (c#/.net shop) I constantly evangelize for it. The fact that this obscure language makes me comfortable enough to recommend to my entire team speaks volumes to the quality and community around it. Cannot recommend it enough.
- slezakattack 8y agoAs an Erlang developer for the past couple years now, I love seeing the adoption and excitement around Elixir and the BEAM. I will admit I always shudder when people very quickly call out on Erlang's syntax as a reason not to use it. Feels like a pretty lame excuse... All that said however, it kind of bugs me when I see posts like this (no matter the language) that go somewhere along the lines of "I managed to introduce language X and it was all rainbows and unicorns! Everybody loves it and work is fun again". Like, you had absolutely no problems with it? In my experience, people don't immediately grasp the actor model or how to manage processes (i.e. should I spawn a process for a short-lived task? should this monitor another process? should I link? should it need supervision?). Given that you're basically changing a methodology amongst your devs, it can be expected that things won't get written "right" the first time. I'm not referring to little idiosyncrasies like coding convention or best practices but literally misunderstanding of gen_servers and supervisors. Sure, perhaps transferring from Ruby to Scala to Elixir helped made the transfer less painful given their similarities but surely there were complications?
- dudul 8y agoYour first comment is kind of funny, because while Elixir's syntax may appear more "esthetic", I find Erlang's way more consistent and logical.
- OvermindDL1 8y agoEntirely agreed. Elixir's Macro's are awesome, and Erlang could definitely use an Elixir-Macro-Like Parse Transform library (could definitely exist), Erlang's syntax I find far more readable, consistent, and logical as well. Elixirs syntax has a lot needless, hard-to-read, noise, but it's not hard to overcome the noise to get the benefits of the overall ecosystem and macros.
- pera 8y agoThis topic is quite subjective, but could you provide some example? Overall Elixir seems to me a bit easier to read, for instance: Elixir: "Hello,How,Are,You,Today" |> String.split(",") |> Enum.join(".") |> IO.puts Erlang: -module(tok). -export([start/0]). start() -> Lst = string:tokens("Hello,How,Are,You,Today",","), io:fwrite("~s~n", [string:join(Lst,".")]), ok.
- jgulbronson 8y agoAwesome read! I was actually an intern on Cees' team when we started writing db2kafka (https://github.com/PagerDuty/db2kafka https://github.com/PagerDuty/db2kafka), and got to contribute a fair amount. It was a really fun language to work with, especially if you enjoy the Actor pattern, and had some nice debugging tools. I'd definitely encourage anyone interested to give it a shot, especially anyone with similar requirements as Pagerduty!
- rs86 8y agoErlang is not remotely based off prolog. It shares the syntax because it was first implemented in prolog.
- nerpderp83 8y agoAre you attempting to confuse the conversation with facts?
- blackrock 8y agoIt seems that Elixir would be a perfect platform for Artificial Intelligence programming. Since Elixir is used for (1) functional programming, and (2) it uses Erlang's OTP Server for massive parallelization. But, I don't seem much activity in this space. What is the probability that Elixir will emerge as the "killer app" for AI development?
- rpm33 8y agoThere is already some work out there since Elixir lends perfectly for parallelization of computation and is also immutable. See: https://www.youtube.com/watch?v=YE0h9DURSOo https://www.youtube.com/watch?v=YE0h9DURSOo and http://www.automatingthefuture.com/blog/2016/9/7/artificial-neural-networks-elixir-and-you http://www.automatingthefuture.com/blog/2016/9/7/artificial-...
- rs86 8y agoIt won't never be even close to native code because of the BEAM overhead, lack of typing, memory layout. It is suited for concurrency not computationally intensive workloads. Not to mention the use of gpus.
- jeremy_k 8y agoThe problem is that BEAM wasn't built to excel at number crunching or doing computationally expensive work. A good explanation here https://stackoverflow.com/questions/11214336/what-makes-erlang-unsuitable-for-computationally-expensive-work https://stackoverflow.com/questions/11214336/what-makes-erla... But I've been reading a lot about this topic too. There are a lot of people out there doing exploratory work to see if Elixir can be a viable solution.
- rs86 8y agoElixir is suited for reliable and fast servers, not computing workloads... It could control other processes but it could hardly compete with native ML libraries. Also calling foreign code from Elixir messes with the beam scheduled if it takes more than a couple millis
- 8y ago