Live data from Hacker News

Elixir at PagerDuty

pagerduty.com

41–50 of 190 posts

Re: Elixir at PagerDuty

#41
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…

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

Re: Elixir at PagerDuty

#42
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…

1. Disallow infix notation abuse through code review. Scalafmt can automate that for you.

2. I mentored a couple novice developers working on a Play codebase, the rough guideline was to use libraries that depend on Scalaz, Cats, Shapeless ... but never import any of them in our codebase. No HKT in our code either. (Nowadays I work with all that on a daily basis, you can keep things reasonable).

3. I think you're mixing up a few unrelated things. Scala's OO model is cleaner than Java's. Implicits abuse is avoidable with frameworks like Play.

Re: Elixir at PagerDuty

#43
post #10
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…

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

What stuff are you running into with this? The vast majority of the ecosystem is on stable, but there are some holdouts. Working on them! I always like to hear people’s pain points, it helps with prioritization.

Re: Elixir at PagerDuty

#44
post #10
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…

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

Has rust ever broken working code in a stable release?

Re: Elixir at PagerDuty

#45
post #18

Earlier quoted context omitted.

There is good interop story for Elixir/Rust. I would not be so sure about money bit either.

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

Or you can just make a remote node out of your C/Java/Rust/whatever code and not worry too much about it crashing your Erlang system.

It's not just crashing either, it's taking a long time to execute a given function in the native code - that can also cause problems for the Erlang system running it.

Re: Elixir at PagerDuty

#46
post #26
post #3

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

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 into Crystal. The future is definitely in compiled/static languages IMO.

Re: Elixir at PagerDuty

#47

As 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, ni…

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

Re: Elixir at PagerDuty

#48
I 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.

Re: Elixir at PagerDuty

#49
post #10

Earlier quoted context omitted.

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

Has rust ever broken working code in a stable release?

Depends on how you define “working”. We have broken some code that used to compile due to soundness issues.

We’ve also made some small changes that in theory can break code but weren’t observed in the wild. The tolerance for that has dropped over time, of course.

Re: Elixir at PagerDuty

#50
post #18

Earlier quoted context omitted.

There is good interop story for Elixir/Rust. I would not be so sure about money bit either.

Just 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 danger of crashing the whole VM only applies to NIFs (native implemented functions), which is a very tight integration of the external code. There are also Ports, which don't carry the same risk of fatal crashes.
Post reply on HN