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

131–140 of 190 posts

Re: Elixir at PagerDuty

#131

Post by dozzie »

fabian2k wrote: post #50
skrebbel wrote: post #27

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…

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.

> There are also Ports, which don't carry the same risk of fatal crashes.

Oh, this is cute statement xD No, ports also carry the same risk as NIFs if you use port drivers, because it's still the same way of running the code, just with different API. You need ports backed by external process to be isolated from the crash, though there's still the problem of such ports eagerly reading all the available data without any backpressure whatsoever, so your BEAM can trigger OOM killer. This is much easier to avoid, fortunately.

Re: Elixir at PagerDuty

#132

Post by mmartinson »

OvermindDL1 wrote: post #111
pg_bot wrote: post #101

Earlier quoted context omitted.

Even better: "Hello,How,Are,You,Today" |> String.replace(",", ".") |> IO.puts()

It still doesn't do the same thing as the erlang code as the elixir example is being run at the staged compile-time instead of run-time like elixir's would be though. And a superfluous `ok` atom is being returned from the erlang code when its `io:fwrite/2` already returns it, plus why call fwrite instead of just write out an iolist directly?! o.O

Ya I get the sense the Erlang example is written a bad faith a little.

Re: Elixir at PagerDuty

#133

Post by mmartinson »

OvermindDL1 wrote: post #112
dopamean wrote: post #103

Earlier quoted context omitted.

Why is it unnecessary?

It's unnecessary in the 'erlang' ecosystem because erlang doesn't have variable rebinding, Elixir 'does' have variable rebinding so it needs some way to distinguish between rebinding and matching, and it was decided to use `^` to mark matching, when honestly I think it would have been smarter to specify it (or something similar) as rebinding. In quite a few cases rebinding leads to bugs (accidentally rebinding someth…

I think I would also prefer there to be no reminding. On the topic of the pin operator though, it seems more clear to me that it's an assertive component of a match, rather than needing to reference all variables in a scope in the case where there was no rebinding, to determine if something matching has already been assigned.

Re: Elixir at PagerDuty

#134

Post by burntsushi »

firebacon wrote: post #122
burntsushi wrote: post #113

Earlier quoted context omitted.

> 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. You don't need any fancy features to do this. Every single one of my Rust CLI programs has done this on stable Rust for years. All you need to do is bubble your errors up to main. If you have destructors that you want to run, then put those in a f…

I would not consider setting an exit code to be a fancy feature, but I guess we are living on the bleeding edge here :) EDIT: I should have said explicitly in my initial comment that I knew about std::process::exit and panic!, but did not consider them to be a clean solution for exiting the program under normal circumstance -- more of an abort() mechanism.

I don't see why. process::exit is perfectly clean from my perspective. You don't need to be on the bleeding edge. This has been possible since Rust 1.0.

Re: Elixir at PagerDuty

#135

Post by mmartinson »

peterwwillis wrote: post #39

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…

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

Re: Elixir at PagerDuty

#136

Post by keithnoizu »

seangrogg wrote: post #105
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…

> 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... I have mixed feelings here. From a purely implementation standpoint I totally agree - I don't particularly enjoy using certain tools at work but that…

I did erlang programming for about a year before switching to elixir for the last 3 years. I have a large server cluster serving 275k sensor devices averaging one report per minute containing 1 to 4 readings (temp, humidity, rainfall, wind speed, heading, etc.) calculating daily, weekly, monthly, yearly, hourly, and smaller high/low/average/tally aggregates and allowing users to setup complex alerts against these values. It would have take me a huge amount longer to write the same in erlang.

The difference between readability and usability of Elixir and Erlang syntax is night and day, especially as someone coming from 20 years of working with imperative languages. I can feel comfortable handing out small tasks to a lay developer in elixir and getting back a response pretty quickly, it has a much easier on boarding. It has it's flaws of course. It's much easier to write programs that will crash in elixir, etc. but that concession with a more approachable syntax and methodology coupled with the benefits of OTP and Beam seems like a much more compelling sell than pure erlang.

Re: Elixir at PagerDuty

#138

Post by MitjaBezensek »

temporaryacc62 wrote: post #115
everdev wrote: post #46

Earlier quoted context omitted.

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…

If only there were types in Elixir to get rid of those damn nulls... Supposedly someone is making a Typescript-like precompiler for Elixir (with ML syntax of course). We are all hoping it succeeds!

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.

Re: Elixir at PagerDuty

#139

Post by inferiorhuman »

steveklabnik wrote: post #117
inferiorhuman wrote: post #110

Earlier quoted context omitted.

Does rustfmt-preview work with bindgen though?

I don’t know what this sentence means.

Bindgen relies on rustfmt. With the codebase I'm using rustfmt-nightly works, but the stable version segfaults. Known issue but that's why I've stuck with rustfmt-nightly.

Re: Elixir at PagerDuty

#140

Post by blackrock »

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

Post reply on HN