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

81–90 of 190 posts

Re: Elixir at PagerDuty

#81

Post by nasmorn »

everdev wrote: post #46
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?

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 you mean your future, you could certainly be right. But if you mean the future of all programming I would like to say that compiled/static languages are in fact the past.

They are super useful and given a complicated enough problem/ sophisticated enough programmer they will look like a good enough solution for all problems. But ... Wordpress

Re: Elixir at PagerDuty

#82

Post by firebacon »

tomjakubowski wrote: post #80
firebacon wrote: post #70

Earlier quoted context omitted.

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

A common pattern is something like: fn main() { if let Err(e) = real_main() { let status = status_from_error(e); // print the error message, or whatever std::process:exit(status); } } fn real_main() -> Result { // ... } And simply returning Result from functions called by real_main that might need to exit the program. I believe that in a recent stable version of Rust, you can make this even simpler and have `main()`…

Yes, currently doing something similar to that, but I'd much rather have it as a first-citizen feature. Returning result directly from main sounds very interesting! I will have to look into that thx.

EDIT: I assume you mean RFC1937? Looks like it isn't implemented yet, so we will probably have to at least another year before we can get it in stable rust. But yes - without having read the entire RFC - I think that was what I was looking for!

Re: Elixir at PagerDuty

#83

Post by pera »

OvermindDL1 wrote: post #66
dudul wrote: post #55

Earlier quoted context omitted.

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.

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.

Re: Elixir at PagerDuty

#84

Post by steveklabnik »

golergka wrote: post #69
steveklabnik wrote: post #43

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.

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.

That's true. I do think that some people are too enthusiastic to recommend nightly; it happens when you have people who are really into where the language is going and want you to see the future rather than use something that works in the present.

Re: Elixir at PagerDuty

#85

Post by steveklabnik »

gamache wrote: post #61
steveklabnik wrote: post #43

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.

It's all good; I appreciate it anyway.

Re: Elixir at PagerDuty

#86

Post by steveklabnik »

firebacon wrote: post #76
rabidferret wrote: post #75

Earlier quoted context omitted.

Unless I'm misunderstanding you, [`std::process::exit`]( https://doc.rust-lang.org/nightly/std/process/fn.exit.html ) does what you want.

std::process::exit does not call Drop traits (at least the last time I tried -- maybe I am doing it wrong?). So for example, if you're relying on Drop to clean up temporary files in the system, that will not happen. Providing no method to call destructors AND exit non-zero feels like a bug or missing feature. EDIT: to expand on this: a suggested workaround is to only call std::process::exit at the very end of the mai…

You're not wrong. The issue is, it's hard to make a good API for this; anything else is basically dealing with global state, and so you don't have a guarantee that something else doesn't re-set it to something else while unwinding is happening, etc. I do have one more thing to say on this, but it fits better in a reply elsewhere in the thread :)

panic! does return a non-zero exit code, but isn't really designed for good end-user output.

Re: Elixir at PagerDuty

#87

Post by rabidferret »

firebacon wrote: post #76
rabidferret wrote: post #75

Earlier quoted context omitted.

Unless I'm misunderstanding you, [`std::process::exit`]( https://doc.rust-lang.org/nightly/std/process/fn.exit.html ) does what you want.

std::process::exit does not call Drop traits (at least the last time I tried -- maybe I am doing it wrong?). So for example, if you're relying on Drop to clean up temporary files in the system, that will not happen. Providing no method to call destructors AND exit non-zero feels like a bug or missing feature. EDIT: to expand on this: a suggested workaround is to only call std::process::exit at the very end of the mai…

Calling `std::process:exit(1)` at the end of main is identical to `return 1`. I'm not sure what your point is with `env_logger::init`. It sounds like you think destructors are run on static items? They aren't. In fact, until very recently you weren't even allowed to have destructors on consts/statics

Re: Elixir at PagerDuty

#88

Post by steveklabnik »

firebacon wrote: post #70
steveklabnik wrote: post #43

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.

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

Interesting, I'll check it out: sounds like a bug in crossbeam. Thanks for letting me know. It's also true that the language and the ecosystem are different things; that's one reason why we're focusing on stabilizing stuff this year, to help move people off of nightly. 1.26 contained a really huge stabilization in this regard. It is a downside of the "put everything in the ecosystem" approach, though.

You're writing a server with hyper directly? Is there a particular reason you're not using one of the frameworks written on top? I may have some advice there, depending.

Re: Elixir at PagerDuty

#89

Post by rabidferret »

steveklabnik wrote: post #86
firebacon wrote: post #76

Earlier quoted context omitted.

std::process::exit does not call Drop traits (at least the last time I tried -- maybe I am doing it wrong?). So for example, if you're relying on Drop to clean up temporary files in the system, that will not happen. Providing no method to call destructors AND exit non-zero feels like a bug or missing feature. EDIT: to expand on this: a suggested workaround is to only call std::process::exit at the very end of the mai…

You're not wrong. The issue is, it's hard to make a good API for this; anything else is basically dealing with global state, and so you don't have a guarantee that something else doesn't re-set it to something else while unwinding is happening, etc. I do have one more thing to say on this, but it fits better in a reply elsewhere in the thread :) panic! does return a non-zero exit code, but isn't really designed for g…

If you don't care about the specific error code as long as it's non-zero, just returning `Result` does what you want on stable now, right?

Re: Elixir at PagerDuty

#90

Post by steveklabnik »

firebacon wrote: post #82
tomjakubowski wrote: post #80

Earlier quoted context omitted.

A common pattern is something like: fn main() { if let Err(e) = real_main() { let status = status_from_error(e); // print the error message, or whatever std::process:exit(status); } } fn real_main() -> Result { // ... } And simply returning Result from functions called by real_main that might need to exit the program. I believe that in a recent stable version of Rust, you can make this even simpler and have `main()`…

Yes, currently doing something similar to that, but I'd much rather have it as a first-citizen feature. Returning result directly from main sounds very interesting! I will have to look into that thx. EDIT: I assume you mean RFC1937? Looks like it isn't implemented yet, so we will probably have to at least another year before we can get it in stable rust. But yes - without having read the entire RFC - I think that was…

Part of it is implemented; see https://play.rust-lang.org/?gist=d442c47833587ddeff2158492b0...

The rest of it makes it even better; it's a bit limited in ways right now.

Post reply on HN