Live data from Hacker News

Elixir at PagerDuty

pagerduty.com

61–70 of 190 posts

Re: Elixir at PagerDuty

#61
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.

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.

I'm just a dabbler and most of my experience is a few months old -- I have no specifics for you, I'm afraid.

Re: Elixir at PagerDuty

#62
post #61

Earlier quoted context omitted.

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.

I'm just a dabbler and most of my experience is a few months old -- I have no specifics for you, I'm afraid.

If you're talking about Rocket that seems to be the largest thing that requires nightly. That said I can count on my hands the number of times I've used nightly over the last 2-ish years. It's pretty rare that you need to do it.

I'll also add that I've actually been really impressed with how much attention Rust takes to not break stable packages. Between crater[1] and how aggressively they've cut point releases to fix any issues that (rarely) happen to slip by.

[1] https://github.com/rust-lang-nursery/crater

Re: Elixir at PagerDuty

#63
post #24

Earlier quoted context omitted.

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.

Fair, C may have been a better example. Where nearly everything is actually just a block of bytes of various lengths and can be intermingled fairly freely with minimal effort to get anything past the compiler. Sometimes useful, but the type system ends up offering few meaningful protections as a consequence.

The types of values and legal conversions between them are well defined in C -- the assumption that everything is just a block of bytes and hence may be casted freely between types is explicitly incorrect (and is what may lead to bad/invalid C code).

However, C does allow you to write code that can not proven to be legal with respect to the formal system of the language and get it to compile, I think that is what you are referring to.

But just because you can write an invalid program does not mean the type system doesn't exist or is flawed. I can also write an invalid Haskell program.

The difference between these two would be that the haskell program can be proven to contain only operations that map to well-defined operations in the formal language model by an automated process, while the same can not be done for C in the general case.

However, just because you can not always prove conformance to a formal model using automated means, doesn't mean that no formal model exists (because it does!).

Re: Elixir at PagerDuty

#64
post #35
post #34

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

You do realize that outside of cloud providers hype "serverless" is a tiny fraction of cloud use let alone overall use.

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

Re: Elixir at PagerDuty

#65
post #45

Earlier quoted context omitted.

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.

Remote nodes have overhead, however if you can handle that overhead then you definitely should use a remote node or Port over a NIF. However, NIF's taking a long time to run is not so much of an issue anymore now that the dirty NIF scheduler is enabled by default in the BEAM.

Re: Elixir at PagerDuty

#66
post #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.

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

Re: Elixir at PagerDuty

#67
post #64
post #35

Earlier quoted context omitted.

You do realize that outside of cloud providers hype "serverless" is a tiny fraction of cloud use let alone overall use.

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

at our scale if we used "serverless" our AWS bill would go from several mil a month to 20+ mil. plus

Re: Elixir at PagerDuty

#68
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 one of the best things about the language.

Re: Elixir at PagerDuty

#69
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.

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.

Things do break if you use nightly – and if you ask for help in the community, "switch to nightly" is a very, very common advice.

Re: Elixir at PagerDuty

#70
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.

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.

Just yesterday our build broke because a cargo update pulled in some dependencies that suddenly required experimental features. I think it was crossbeam via hyper or tokio.

Also, while I recognize it's a third party project, the hyper API keeps changing faster than I can adapt my code. If you are aware of a more stable HTTP server, ideally one that has proper TLS support and support for unix domain sockets, I would be very interested.

EDIT: on the other hand, after working with rust daily for ~1.5 years, I have only run into one compiler bug and had zero actual bugs in my application due to language/compiler updates so far. There have been a few occasions were essential features were missing from the standard library/language though and several times were we had to backport some code to an older, stable rust version that we're one (when a developer had mistakenly tested their code locally with a newer version).

The highest up on my wish list would be that - as I understand it - you can not currently exit the process cleanly (EDIT: early) with a non-zero exit code in stable rust. That makes it pretty hard to implement good command line utilities. Happy to be corrected if I am wrong on this one though.

Post reply on HN