Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

schneider.dev

Post reply on HN
Print view View original

51–60 of 155 posts

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#51

Post by jsjohnst »

lame88 wrote: post #41
stephan83 wrote: post #36

Elixir and OTP are really nice, but I'm frustrated by the type system, even with typespecs. I finally gave in and started learning Haskell. I would still choose Elixir/Phoenix for some web apps though.

Expect a long journey if you’re trying to get to the state where you can make a web app. I am making a conjecture here but from my limited but nontrivial experience it seems libraries in the applications ecosystem of haskell apply the most advanced features they know of to solve their problems. That would normally be fine, but they do not abstract away this complexity; due to the type system’s rigor, these choices ar…

> I am making a conjecture here but from my limited but nontrivial experience it seems libraries in the applications ecosystem of haskell apply the most advanced features they know of to solve their problems.

Apologies to others for the “me too” reply, but I wanted to let you know you aren’t alone, I also feel this way. It’s intellectual masturbation (without any reward/benefit), IMHO.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#52

Post by quickthrower2 »

jsjohnst wrote: post #51
lame88 wrote: post #41

Earlier quoted context omitted.

Expect a long journey if you’re trying to get to the state where you can make a web app. I am making a conjecture here but from my limited but nontrivial experience it seems libraries in the applications ecosystem of haskell apply the most advanced features they know of to solve their problems. That would normally be fine, but they do not abstract away this complexity; due to the type system’s rigor, these choices ar…

> I am making a conjecture here but from my limited but nontrivial experience it seems libraries in the applications ecosystem of haskell apply the most advanced features they know of to solve their problems. Apologies to others for the “me too” reply, but I wanted to let you know you aren’t alone, I also feel this way. It’s intellectual masturbation (without any reward/benefit), IMHO.

Haskell is a funny beast because I get a lot of joy from “conquering” the next level up (like a game) but in terms of productivity I’m not getting a lot done. OTOH in more pedestrian languages I’m using that brain BHP on getting stuff done. I really got into the Haskell thing a while back, going to meetups etc. but getting a job using Haskell is hard unless you’ve got experience already and want to take a pay cut.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#53

Post by sk5t »

anthony_doan wrote: post #13
adamnemecek wrote: post #4

Ok, for backend, I’m deciding between rust with actix, jvm (kotlin + akka/quasar) or elixir. I kinda know the theoretical differences but I’m curious what hn thinks. Has someone actually deployed things in some of these. I do have preference towards rust but maybe there’s something better.

Erlang/Elixir's VM is gear toward high uptime, low latency, and highly concurrent. https://stressgrid.com/blog/100k_cps_with_elixir/ What it's not good at is numerical computation. As for the others I have no clue but I am sure jvm won't be as low latency as Elixir's VM since it's not a preemptive scheduler.

I think a lot of folks writing low latency code in C, or for the JVM, would be surprised at the suggestion a lack of preemptive scheduler makes their work futile.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#54

Post by onebot »

I have just starting learning Elixir and Phoenix. It seems like a solid replacement for Rails. But I keep getting hung up on performance. With React, it seems like you are developing more API back-end, then web server back-end (if that makes sense). But when you look at the performance compared to Go and the steeper learning curve, why not just use Go? Kubernetes really solves the share-nothing let-it-fail aspect. Obviously, Erlang/Elixir are hands-down a good fit for fault tolerant distributed systems where performance may not be as critical or you can use NIF. But outside chat and a few other use-cases, not sure the majority of web services falls into this. However, the functional code is so nice. Anyways, any input on how to convince engineering leadership how Elixir might be better than Go would be helpful.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#55

Post by stephan83 »

lame88 wrote: post #41
stephan83 wrote: post #36

Elixir and OTP are really nice, but I'm frustrated by the type system, even with typespecs. I finally gave in and started learning Haskell. I would still choose Elixir/Phoenix for some web apps though.

Expect a long journey if you’re trying to get to the state where you can make a web app. I am making a conjecture here but from my limited but nontrivial experience it seems libraries in the applications ecosystem of haskell apply the most advanced features they know of to solve their problems. That would normally be fine, but they do not abstract away this complexity; due to the type system’s rigor, these choices ar…

Thank you for the input. Maybe I will never get to the point where I can comfortably make a web app, but learning the language has been a fun experience so far. I've heard good things about Scala and Akka.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#56

Post by bnchrch »

benwilson-512 wrote: post #32

Hey folks! Co-Author of Absinthe here, happy to answer any questions about it. The post here is good, although these days we recommend using Dataloader vs Absinthe.Ecto. Dataloader really extends the idea behind Absinthe.Ecto while providing in request caching, pluggable backends, and easier query manipulation.

I can second this, we've been using dataloader in production for almost 2 years now. Fantastic library.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#57

Post by iends »

onebot wrote: post #54

I have just starting learning Elixir and Phoenix. It seems like a solid replacement for Rails. But I keep getting hung up on performance. With React, it seems like you are developing more API back-end, then web server back-end (if that makes sense). But when you look at the performance compared to Go and the steeper learning curve, why not just use Go? Kubernetes really solves the share-nothing let-it-fail aspect. Ob…

For non-stateful services, it seems very difficult to me to convince people to use Erlang/Elixir over Go. It also seems to me that Go is going to be more maintainable over time than Elixir. Also, Elixir has smaller corporate backing compared to Go.

fwiw, I work at a telecommunications company and I've had no success convincing anybody to use either Go or Erlang/Elixir over Java (& Clojure).

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#58

Post by chrisco255 »

sergiotapia wrote: post #9

When you get to the absinthe part you lose me. It's the same gut feeling I had when I see Redux where it works but it was created at the very beginning of this entire workflow discovery and better tools/approaches have since come out.

Redux is still a solid choice. Apollo is used more often now because it handles a lot of GraphQL optimization but it's by no means a panacea. And sometimes, despite being an advocate of Apollo, I miss the simplicity of Redux.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#60

Post by onebot »

iends wrote: post #57
onebot wrote: post #54

I have just starting learning Elixir and Phoenix. It seems like a solid replacement for Rails. But I keep getting hung up on performance. With React, it seems like you are developing more API back-end, then web server back-end (if that makes sense). But when you look at the performance compared to Go and the steeper learning curve, why not just use Go? Kubernetes really solves the share-nothing let-it-fail aspect. Ob…

For non-stateful services, it seems very difficult to me to convince people to use Erlang/Elixir over Go. It also seems to me that Go is going to be more maintainable over time than Elixir. Also, Elixir has smaller corporate backing compared to Go. fwiw, I work at a telecommunications company and I've had no success convincing anybody to use either Go or Erlang/Elixir over Java (& Clojure).

That’s ironic considering that Erlang was designed for telecommunications.

But I think statefulness is the right context between the two.

Why do you think Go would be more maintainable?

Post reply on HN