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

121–130 of 190 posts

Re: Elixir at PagerDuty

#121

Post by OvermindDL1 »

OvermindDL1 wrote: post #116
temporaryacc62 wrote: post #115

Earlier quoted context omitted.

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!

Eh, as far as I know I'm the only one doing that, and even then only as an experiment/playground, and I don't have the time to work on it lately (have to pay the bills after all). It's not compiling to elixir, but the `alpaca` language compiles to the BEAM (via erlang core I think) so it gets you close, although they are not black boxing messages sadly. If you know of someone else doing typing experiments on top of e…

Oh yes! Elchemy! How'd I forget about that one (I keep pushing it around!)! ^.^;

It is based on Elm so it has a severely limited type system but it is the most complete on Elixir so far. :-)

Re: Elixir at PagerDuty

#122

Post by firebacon »

burntsushi wrote: post #113
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…

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

Re: Elixir at PagerDuty

#123

Post by dqv »

dxhdr wrote: post #96
pera wrote: post #83

Earlier quoted context omitted.

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.

I'm okay with this trade off instead of having to do Variable0, Variable1, ..., VariableN. It would be cool to have an option to turn off rebinding for those who don't want it (and then not requiring the pin).

Re: Elixir at PagerDuty

#124

Post by jvican »

runT1ME wrote: post #97
jvican wrote: post #41

Earlier quoted context omitted.

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

Productivity is defined in subjective terms. I know several success stories of companies that use Scala as a better Java and find themselves more productive. That doesn't mean they don't do any functional programming -- it just means they don't need to use Scalaz/cats to be happy Scala developers. The OP is mostly concerned about Scala being a language that encourages the use of monad transformers and catamorphisms all over the place. What I'm trying to illustrate is that nothing could be farther from the truth.

Re: Elixir at PagerDuty

#125

Post by jvican »

AzzieElbab wrote: post #94
jvican wrote: post #41

Earlier quoted context omitted.

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

Lisp doesn't have any way to define those FP constructs and it's one of the first functional programming languages ever. I think you're being misled by Haskell.

Re: Elixir at PagerDuty

#127

Post by rs86 »

rapind wrote: post #118
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…

Instagrammification of tech blogs.

Agree

Re: Elixir at PagerDuty

#128

Post by rs86 »

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.

I think the AST is easier to see in erlang.

Re: Elixir at PagerDuty

#129

Post by qaq »

Touche wrote: post #71
qaq wrote: post #67

Earlier quoted context omitted.

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

You're not a startup.

Isn't a goal of startup to grow? You lock yourself into a model where you compute spend is 10X that of your competitors you not gonna get very far.

Re: Elixir at PagerDuty

#130

Post by dozzie »

skrebbel wrote: post #27
qaq wrote: post #18

Earlier quoted context omitted.

There is good interop story for Elixir/Rust. I would not be so sure about money bit either.

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 idea of [...] writing native code that has a tremendously small likelihood of crashing is very appealing. Until recently, no such technology was available but Rust changed that.

No such technology was available, barring maybe Ada or some other languages.

Post reply on HN