Live data from Hacker News

Elixir at PagerDuty

pagerduty.com

51–60 of 190 posts

Re: Elixir at PagerDuty

#51
post #46
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?

You're right that the major downside I can see is the ecosystem is not as big. But when I jumped into Rails over a decade ago, the Ruby/Rails ecosystem was not huge yet either. But, static typing and being able to compile and deploy a binary is a pretty sweet developer experience. And the syntax is nearly identical to Ruby with a few nice additions. Many companies like ThoughtBot (a huge Ruby adopter) are jumping int…

[deleted]

Re: Elixir at PagerDuty

#52
post #14

Earlier quoted context omitted.

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

Elixir 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?)

> Does anyone make weakly typed languages anymore?

I don't think anybody ever did. The definition of "strong" and "weak" seem to be entirely subjective; and of course everybody considers their favourite language to be "strongly typed". It's like a reverse no-true-scotsman.

Re: Elixir at PagerDuty

#53

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

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

I know what you mean. Even things like error handling in Scala have divergent paradigms, to the point where we had one Scala consultant at the company I worked for using exceptions, and another trying to use Eithers.

I have to say though, coming from a C++ background, Scala still feels much more beautiful, clean, and safe than C++... but then, almost everything does ;)

Re: Elixir at PagerDuty

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

Re: Elixir at PagerDuty

#55

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.

Re: Elixir at PagerDuty

#56
post #6

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

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…

case classes and implicits are almost the exact opposite of OO practices.

Re: Elixir at PagerDuty

#57
post #14

Earlier quoted context omitted.

Elixir 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?)

Strongly typed meaning that Elixir/Erlang don't allow: 1 + "some string" + [A,List,Of,Somethings] Compared to javascript where: 1 + "2" == "12" Statically typed means that variables and functions hold or return specific types which can be determined before execution.

The result add(1: Int, "2": String) -> "12": String can be achieved in any language, regardless of how strict the type system is. All your example shows is that in elxir no such `add(int, string)` operation is provided as part of the standard library/environment, while in javascript, it is.

The "+" (operator) case is only special in languages that do not implement operator overloading -- it is completely orthogonal to the type system.

Re: Elixir at PagerDuty

#58
post #6

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

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)

Re: Elixir at PagerDuty

#59
post #6

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

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…

We run a large (1M+ LOC) Scala codebase and don’t have these particular issues (we have other issues like bitrot in libraries but that’s the same in all languages).

You need to sort of put your foot down on using out there FP stuff like some parts of scalaz and turning your code into line noise. The non-FP parts are nice and useful though.

I can go on for days on how someone wrote some unreadable Scalaz that had atrocious performance (even with @tailrec) and someone rewrites it in plain Scala for a 100x perf win.

Still.. would I use scala again? Yes, but mainly because it allows you to use high quality Java libraries that are unmatched by any other language. It’s also just much nicer than Kotlin.

We also really like Akka...

Re: Elixir at PagerDuty

#60
post #24

Earlier quoted context omitted.

Strongly typed meaning that Elixir/Erlang don't allow: 1 + "some string" + [A,List,Of,Somethings] Compared to javascript where: 1 + "2" == "12" Statically typed means that variables and functions hold or return specific types which can be determined before execution.

Type coercion does not equal weak typing -- I submit JS and Perl as examples where types are strong but there is a coercion protocol dependent on which types an operator expects around it.

If we are being pedantic, what is going on here is not type coercion.

If it were type coercion, we would expect the add function to have either of these two behaviours:

  - coerce the input arguments to strings, i.e. implicitly accept two strings and return another string

  - coerce the input arguments to integers, i.e. implicitly accept two integers and return an integer
However, that is not what is happening here.

Of course, in Javascript it is implemented as a function that takes the theoretical "Any" type and decides what do do at runtime. But in a statically type language, the equivalent mechanism would be dynamic/multiple dispatch (or a static overload, possibly in combination with a generic/template method) -- not type coercion.

Post reply on HN