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

91–100 of 190 posts

Re: Elixir at PagerDuty

#91

Post by firebacon »

rabidferret wrote: post #87
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…

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

> I'm not sure what your point is with `env_logger::init`

That most of my programs have some global (i.e. "for the runtime of the program") stuff that is setup at the beginning of main. And that some of that might want to Drop when the program exits, for example to delete a temporary directory. Now, if I want to return a non-zero exit code I can not do so while still getting all this global stuff destructed correctly (or use a workaround like having a wrapper-main).

> Calling `std::process:exit(1)` at the end of main is identical to `return 1`.

The thing is that it is actually not the same with respect to destructors -- the documentation explicitly calls that out. See also the C++ comparison in my other comment.

Re: Elixir at PagerDuty

#92

Post by steveklabnik »

rabidferret wrote: post #89
steveklabnik wrote: post #86

Earlier quoted context omitted.

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?

That's true, but then you have to juggle Results as your return type everywhere. It's probably a good idea overall, but some people don't want to do that. And yes, you don't get to pick the code. Yet!

Re: Elixir at PagerDuty

#93

Post by joelbluminator »

freedomben wrote: post #30
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?

Not OP, and not Crystal, but comparing Phoenix ecosystem with Rails is pretty doable. There are a lot of packages available. Obviously not as much as on rubygems, but one can get a pretty good feel for the overall developer experience. My enjoyment of rails isn't really about the wide array of gems available anyway. It's the paradigms and community standards.

Rails is also very powerful because of hundreds of thousands of answers on Stackoverflow and countless blogs. It's not easy to reach that level.

Re: Elixir at PagerDuty

#94

Post by AzzieElbab »

jvican wrote: post #41
gamache wrote: post #6

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

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 is simply not true. First, there is no Haskell influence on the language.

Since Scala has no build-in way to define FP constructs(monads, functors.. ), cats and scalaz are practically inseparable from the language itself when you try to go beyond the basics in FP. So, it is very easy to see where all the confusion is coming from

Re: Elixir at PagerDuty

#95

Post by firebacon »

steveklabnik wrote: post #88
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…

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…

We started using Iron, but later switched to just using hyper because that seemed easier and like a smaller API surface to target. I'm not really working on a web application so I need zero of the routing/web features of these frameworks.

I do need a lot of pretty specific other features though. Unix domain sockets are currently a must (luckily that works with hyperlocal).

The code runs on a pretty resource constrained system so I like the low level of control that hyper gives me of the request/response chunking behaviour (I can not afford to buffer large requests in memory and what exactly I do with the body payload differs between API calls).

One thing that would be lovely is proper TLS/HTTPS support. I need support for x509 client certificates and I need to get access to the full client certificate data, ideally including the full chain that signed it from the request handler. I have to admit that I currently run a hacked together nginx in front of my app and put this stuff into HTTP headers (hence the unix domain sockets) because I could not get it to work with rust ecosystem libraries.

EDIT: The TLS stuff is also true for the HTTP client case. Currently using the libcurl rust binding because it's the only thing that implements all the features I need (--cainfo, --cert, --key, --resolv). Also it needs to run on OpenSSL or something else that supports x509v3 extended attributes (subtree constraints).

Re: Elixir at PagerDuty

#96

Post by dxhdr »

pera wrote: post #83
OvermindDL1 wrote: post #66

Earlier quoted context omitted.

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.

> This topic is quite subjective, but could you provide some example?

Elixir's pin operator is a good example of unnecessary complexity.

Re: Elixir at PagerDuty

#97

Post by runT1ME »

jvican wrote: post #41
gamache wrote: post #6

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

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…

>They just use Scala because it's a better Java that boosts their productivity.

I spent three years on the 2nd largest Scala 'team' in the U.S (first as an engineer, then leading a sub team), the problem is that using Scala as a 'better java' doesn't really buy you much productivity wise. A small percentage of sub teams tried using Scala this way and hit a lot of road blocks with the unfamiliar syntax, immature tooling, and other quirks.

The teams that had huge productivity gains were the ones who leaned heavily on the functional features WHILE caring about overall readability. That means yes, we used Scalaz but we discouraged the omission of dots and parentheses (as you mentioned), discouraged operator overloading/symbolic methods, and were very deliberate about when to reach for features such as HKTs or some of the more unfamiliar features of Scalaz.

Overall it lead to a very productive and fun development experience, and at the same time illuminated many ways in which the Scala ecosystem could also be improved.

Re: Elixir at PagerDuty

#98

Post by firebacon »

steveklabnik wrote: post #90
firebacon wrote: post #82

Earlier quoted context omitted.

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.

Oh nice! Will start using that as soon as we get to 1.26 :) -- currently stuck on 1.24 (upgrading takes a bunch of work since we're building under openembedded/bitbake, so I wait until the new version hits the upstream layer)

Re: Elixir at PagerDuty

#99

Post by steveklabnik »

firebacon wrote: post #95
steveklabnik wrote: post #88

Earlier quoted context omitted.

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…

We started using Iron, but later switched to just using hyper because that seemed easier and like a smaller API surface to target. I'm not really working on a web application so I need zero of the routing/web features of these frameworks. I do need a lot of pretty specific other features though. Unix domain sockets are currently a must (luckily that works with hyperlocal). The code runs on a pretty resource constrain…

Cool cool, that makes sense. I probably don't have good advice for you then; what I will say is that things should end up much more stable in a few months, but there's a massive async/await/impl Trait/futures/tokio/hyper upgrade going on, so stuff is a bit more chaotic than usual. Once that's over though, stuff should be solid for quite a whole.

I don't know if rustls supports your use-case for TLS, but you may want to check it out.

Thanks again. It's really invaluable to hear about these kinds of things.

Re: Elixir at PagerDuty

#100

Post by steveklabnik »

vvanders wrote: post #79
inferiorhuman wrote: post #73

Earlier quoted context omitted.

Bindgen also wants nightly so if you're doing any FFI stuff you may be tethered to nightly.

You sure about that? 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.

I'm sitting next to bindgen's author in meatspace right now and he says yes, it has been on stable for a long time.
Post reply on HN