Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir at PagerDuty

pagerduty.com

Post reply on HN
Print view View original

181–190 of 190 posts

Re: Elixir at PagerDuty

#181

Post by mercer »

dxhdr wrote: post #96
pera wrote: post #83

Earlier quoted context omitted.

This 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.

> This topic is quite subjective, but could you provide some example? Elixir's pin operator is a good example of unnecessary complexity.

I vaguely recall that this particular choice is one that the language's creator also regrets.

Re: Elixir at PagerDuty

#182

Post by mercer »

dudul wrote: post #55
slezakattack wrote: post #54

As 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 introd…

Your first comment is kind of funny, because while Elixir's syntax may appear more "esthetic", I find Erlang's way more consistent and logical.

I also found Elixir to sometimes be a bit too 'messy' in it syntax. A bunch of it made more sense when I understood why the choice had been made.

The one that I still feel uncomfortable with, and where I haven't heard a proper justification, is how you can leave out [] for a keyword list when it's the last function parameter (I think they call it an options list?).

It's already a bit confusing how a keyword list translates to a list of tuples, so adding that bit of sugar just further confuses things. It reminds me too much of Ruby's implicit block parameter (or whatever it's called), which I never was a fan of.

Other than that Elixir might be my one of my favorite programming languages.

Re: Elixir at PagerDuty

#183

Post by mercer »

pmontra wrote: post #158
pera wrote: post #83

Earlier quoted context omitted.

This 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.

This example captures extremely well what I don't like in Elixir: verbosity. I'm so much more happy writing the equivalent Ruby code: puts "Hello,How,Are,You,Today".split(",").join(".") It's value.method.method vs value |> Module.function |> Module.function. Alias is not a general solution because of conflicts. Disclaimer: I use Elixir in projects for customers and I like it. Still, it's too verbose and I'm not using…

Interesting. I found it immensely liberating to be able to fully separate the functions from the data they operate on. I can see how it might feel verbose though.

Re: Elixir at PagerDuty

#184

Post by mercer »

golergka wrote: post #68
jxub wrote: post #7

My 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…

When I started using Diesel (Rust ORM) I was surprised to find the library's author answering all of my routine and sometimes even idiotic questions on gitter, and all the general help chats have been incredibly helpful – every time I asked the question, people actually spent time and effort to understand my code and what I'm trying to do. I still don't quite understand what makes Rust community this way, but it's on…

That's awesome to hear! I've had similar experiences with Elixir. On the IRC #elixir channel, I've more than once seen Jose Valim (the language creator) or Chris McCord (Phoenix head honcho) answer relatively inane questions about CSS or beginner questions about Elixir. Always felt heart-warming to see, and made me try and actively help out more so those dudes can focus on their work!

Re: Elixir at PagerDuty

#185

Post by mercer »

_asummers wrote: post #145
MitjaBezensek wrote: post #138

Earlier quoted context omitted.

This is probably my only gripe with it. I really like static types, since the tools can be so much better in that case. VSCode + ElixirLS is ok, but far from Elm, Typescript or C# in that regard. I've been trying out Dialyzer and Credo, but it all seems so clunky to use.

If you haven't seen the new Dialyzer messages in Dialyxir, I just finished a big effort to improve those messages dramatically for Elixir consumption. Release is in RC currently.

Thanks a ton for your work!

Re: Elixir at PagerDuty

#186

Post by mercer »

joelbluminator wrote: post #160
cutler wrote: post #26

Earlier quoted context omitted.

How 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?

This. If I was a CTO I would never ever choose Crystal, or Elixir, or Kotlin. Give me a proven, "old", battled tested framework with tons of resources that's easy to teach, learn and get sh done with. I'd choose PHP over Elixir for a new business.

I get the idea behind your comment, but without context it's pretty stupid. There are plenty of use cases where Elixir might be a much better choice than PHP, but it depends entirely on what you're trying to do. I sincerely hope you're not a CTO of a company where PHP is not the right approach...

(that said, I do agree that often PHP is a fine choice, and people might overcomplicate things needlessly by choosing something else)

Re: Elixir at PagerDuty

#187

Post by mercer »

brightball wrote: post #8

Great 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

I'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.

Re: Elixir at PagerDuty

#188

Post by mercer »

dmitriid wrote: post #58
gamache wrote: post #6

Earlier quoted context omitted.

I'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…

Elixir drops parentheses in function calls, too. Unless it's an anonymous function. Or unless it's a function you pipe to. There are other syntax quirks as well. A very very very opinionated take on Elixir syntax: https://medium.com/@dmitriid/in-which-i-complain-about-elixi... :) (Note: I haven't touched Elixir in a while, so some of the things there may be wrong)

The formatter, as Ndymium mentions, fixes a lot of this.

Optional parentheses were one of my main issues with Elixir, but once I understood why this choice was made, and what with the formatter judiciously adding them back in, I'm much happier.

(I recall having tons of issues when using the pipe operator + leaving out parentheses. Happy that these aren't much of an issue anymore.)

Re: Elixir at PagerDuty

#189

Post by pmontra »

mercer wrote: post #183
pmontra wrote: post #158

Earlier quoted context omitted.

This example captures extremely well what I don't like in Elixir: verbosity. I'm so much more happy writing the equivalent Ruby code: puts "Hello,How,Are,You,Today".split(",").join(".") It's value.method.method vs value |> Module.function |> Module.function. Alias is not a general solution because of conflicts. Disclaimer: I use Elixir in projects for customers and I like it. Still, it's too verbose and I'm not using…

Interesting. I found it immensely liberating to be able to fully separate the functions from the data they operate on. I can see how it might feel verbose though.

I don't feel liberated when I program in Elixir but the other languages I use for customers are Ruby, Python and JavaScript, which are quite liberal. It's been so long since I used Java that I can't really appreciate anymore how big the difference is. For sure I don't want to go back to those times.

IMHO "this is a string" |> String.split(" ") doesn't fully separate the data from the function. It's String.split after all and it won't work with an input of any other type.

However, at least in the case of languages with duck typing, some_object.split(" ") works with an object of type String and with any other class that implements a split method that takes a string as argument. Then the rest of the code must be able to keep handling the duck typed object.

Probably this isn't the way you are thinking about data/code separation, still it's a kind of separation.

Re: Elixir at PagerDuty

#190

Post by mercer »

pmontra wrote: post #189
mercer wrote: post #183

Earlier quoted context omitted.

Interesting. I found it immensely liberating to be able to fully separate the functions from the data they operate on. I can see how it might feel verbose though.

I don't feel liberated when I program in Elixir but the other languages I use for customers are Ruby, Python and JavaScript, which are quite liberal. It's been so long since I used Java that I can't really appreciate anymore how big the difference is. For sure I don't want to go back to those times. IMHO "this is a string" |> String.split(" ") doesn't fully separate the data from the function. It's String.split after…

Well, I came from Javascript/Ruby/Python (and still like those too), so for me it really was the functional nature of Elixir that felt 'liberating'.

Using String.split() instead of an method call on the string is just one of the reasons I like this rather stricter separation between data and code, and I do see how in isolation it's not all that great.

That said, I still enjoy the more OO languages and rather like using some of the FP things I've learned inside those. And sometimes it does feel convenient to not be pushed into one particular style of coding. So perhaps 'liberating' is not the best choice of words :).

Post reply on HN