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

171–180 of 190 posts

Re: Elixir at PagerDuty

#171

Post by rs86 »

blackrock wrote: post #140

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?

Elixir is suited for reliable and fast servers, not computing workloads... It could control other processes but it could hardly compete with native ML libraries. Also calling foreign code from Elixir messes with the beam scheduled if it takes more than a couple millis

Re: Elixir at PagerDuty

#172

Post by rs86 »

rpm33 wrote: post #154
blackrock wrote: post #140

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?

There is already some work out there since Elixir lends perfectly for parallelization of computation and is also immutable. See: https://www.youtube.com/watch?v=YE0h9DURSOo and http://www.automatingthefuture.com/blog/2016/9/7/artificial-...

It won't never be even close to native code because of the BEAM overhead, lack of typing, memory layout. It is suited for concurrency not computationally intensive workloads. Not to mention the use of gpus.

Re: Elixir at PagerDuty

#173

Post by inferiorhuman »

steveklabnik wrote: post #170
inferiorhuman wrote: post #167

Earlier quoted context omitted.

I'm using bindgen to generate bindings for radare2. But I'm also using TryFrom, so I'm not likely to move off of the nightly toolchain any time soon. Before I ended up going down the TryFrom rabbit hole I ran into two issues with bindgen: 1.) Bindgen segfaults with the ancient LLVM on OSX 10.9. Issue #1006. Solution: use LLVM >= 5 binaries from the LLVM site. 2.) Stable (deprecated) rustfmt causes bindgen to segfault…

What happens if you uninstall the rustfmt-nightly and use the component instead? (TryFrom is being stabilized fairly soon, it got caught up in some silly stuff but is basically good to go)

So on the mac, something's going on and even with LIBCLANG_PATH set I'm still getting a segfault in some clang stuff. On the BSD box, rustfmt-nightly allows everything to work. Using `cargo install --force rustfmt` will provoke bindgen into reporting an internal error:

Custom { kind: Other, error: StringError("Internal rustfmt error") }

I get the same results if I call the bindgen executable or have build.rs call the bindgen API. I've stuck with having build.rs call the bindgen executable because if I use the bindgen API, compilation is SLOW.

Re: Elixir at PagerDuty

#174

Post by steveklabnik »

inferiorhuman wrote: post #173
steveklabnik wrote: post #170

Earlier quoted context omitted.

What happens if you uninstall the rustfmt-nightly and use the component instead? (TryFrom is being stabilized fairly soon, it got caught up in some silly stuff but is basically good to go)

So on the mac, something's going on and even with LIBCLANG_PATH set I'm still getting a segfault in some clang stuff. On the BSD box, rustfmt-nightly allows everything to work. Using `cargo install --force rustfmt` will provoke bindgen into reporting an internal error: Custom { kind: Other, error: StringError("Internal rustfmt error") } I get the same results if I call the bindgen executable or have build.rs call the…

Not cargo install, the

    rustup component add rustfmt-preview

Re: Elixir at PagerDuty

#175

Post by cutler »

everdev wrote: post #119
joelbluminator wrote: post #93

Earlier quoted context omitted.

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.

Another reason why JavaScript is unfortunately so popular.

Someone please shoot Javascript and put an end to this misery.

Re: Elixir at PagerDuty

#176

Post by methyl »

bradgessler wrote: post #147
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…

How interesting would it be to read the article about the company that looked at doing the big, dramatic rewrite, but didn’t, and was successful? This has happened at my company with a service called Firehose, which is basically PubSub over WS and HTTP written in Ruby Event Machine. It’s unstylish for a lot of technical reasons and an eng even tried to rewrite it in Elixir. We ended up scraping the rewrite project be…

> eng even tried to rewrite it in Elixir. We ended up scraping the rewrite project because the Ruby code just works and rarely gives us any problems in production.

If your Ruby code just worked, why did you try to rewrite it in Elixir?

Re: Elixir at PagerDuty

#177

Post by eggy »

blackrock wrote: post #140

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?

There’s the 2012 or 2013 book by Gene Sher, “Handbook of Neuroevolution Through Erlang”. I was working on writing some of the code in Elixir to learn Elixir, but gave up due to inexperience and I lost my interest in Elixir when the Erlang code resonated more with me.

Re: Elixir at PagerDuty

#178

Post by inferiorhuman »

steveklabnik wrote: post #174
inferiorhuman wrote: post #173

Earlier quoted context omitted.

So on the mac, something's going on and even with LIBCLANG_PATH set I'm still getting a segfault in some clang stuff. On the BSD box, rustfmt-nightly allows everything to work. Using `cargo install --force rustfmt` will provoke bindgen into reporting an internal error: Custom { kind: Other, error: StringError("Internal rustfmt error") } I get the same results if I call the bindgen executable or have build.rs call the…

Not cargo install, the rustup component add rustfmt-preview

Results:

  $ cargo uninstall rustfmt && rustup component add rustfmt-preview
      Removing /home/alex/.cargo/bin/cargo-fmt
      Removing /home/alex/.cargo/bin/rustfmt
  info: downloading component 'rustfmt-preview'
  info: installing component 'rustfmt-preview'
  $ bindgen bindings.h -- -I/usr/local/include/libr > /dev/null
  Custom { kind: Other, error: StringError("Cannot find binary path") }
  $ rustc --version
  rustc 1.28.0-nightly (29f48ccf3 2018-06-03)
  $ cat bindings.h 
  #include 
  #include 
  #include 
  #include 
  #include

Re: Elixir at PagerDuty

#179

Post by steveklabnik »

inferiorhuman wrote: post #178
steveklabnik wrote: post #174

Earlier quoted context omitted.

Not cargo install, the rustup component add rustfmt-preview

Results: $ cargo uninstall rustfmt && rustup component add rustfmt-preview Removing /home/alex/.cargo/bin/cargo-fmt Removing /home/alex/.cargo/bin/rustfmt info: downloading component 'rustfmt-preview' info: installing component 'rustfmt-preview' $ bindgen bindings.h -- -I/usr/local/include/libr > /dev/null Custom { kind: Other, error: StringError("Cannot find binary path") } $ rustc --version rustc 1.28.0-nightly (29…

Okay. Let’s get that bug re-opened!

Re: Elixir at PagerDuty

#180

Post by nasmorn »

handbanana wrote: post #114
nasmorn wrote: post #81

Earlier quoted context omitted.

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

Why are they a thing of the past?

Because in the past they dominated everything. This will not happen again. For some problems/people the ease of dynamic languages are simply more important than the correctness/speed issues you deem as paramount.

I don’t mean no one will or should use static languages but believing they will once again dominate like in the 80s and 90s is an illusion imo

Post reply on HN