Earlier quoted context omitted.
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
Elixir at PagerDuty
71–80 of 190 posts
Re: Elixir at PagerDuty
#72Earlier quoted context omitted.
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
#73Earlier quoted context omitted.
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 fi…
Re: Elixir at PagerDuty
#74Re: Elixir at PagerDuty
#75Earlier 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…
Re: Elixir at PagerDuty
#76Earlier 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…
Unless I'm misunderstanding you, [`std::process::exit`]( https://doc.rust-lang.org/nightly/std/process/fn.exit.html ) does what you want.
EDIT: to expand on this: a suggested workaround is to only call std::process::exit at the very end of the main function. But consider stuff like "env_logger::init". What about that? Ok, that doesn't use Drop and if it did you could put it into it's own scope I guess - so there are workarounds - but it in my opinion that gets pretty ugly. Comparing to c++, std::process::exit or panic! is like abort(), but what I want is a "return 1" from main.
Re: Elixir at PagerDuty
#77As 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…
That said, I wouldn't advocate jumping into Phoenix with zero Elixir knowledge. You'll have a tough time. And knowing about OTP/supervision is also recommended because you'll be much better off in the long term. I don't think you can avoid it forever.
Re: Elixir at PagerDuty
#78How is the library ecosystem with elixir? Currently I'm usually using Go where I have a library for anything and I'm quite apprehensive to start using elixir if there's a lack of libraries.
Sometimes there are split clients for what I wish had a community recommended or be in the std lib. For example HTTPotion[2] vs HTTPoison[3] (names are _super_ similar and sometimes confusing).
[1] https://github.com/whatyouhide/redix/issues/77
Re: Elixir at PagerDuty
#79Earlier quoted context omitted.
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 fi…
Bindgen also wants nightly so if you're doing any FFI stuff you may be tethered to nightly.
I've been using bindgen for ages on stable and just grabbed the latest version on an empty project and it still works for me.
Re: Elixir at PagerDuty
#80Earlier 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…
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()` return a Result directly.
edit: not quite as simple as I described, but maybe more powerful because of the Termination trait: https://github.com/rust-lang/rfcs/blob/master/text/1937-ques... see: https://github.com/rust-lang/rfcs/blob/master/text/1937-ques...
fn main() -> Result {
let mut stdin = io::stdin();
let mut raw_stdout = io::stdout();
let mut stdout = raw_stdout.lock();
for line in stdin.lock().lines() {
stdout.write(line?.trim().as_bytes())?;
stdout.write(b"\n")?;
}
stdout.flush()
}