Live data from Hacker News

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

schneider.dev

11–20 of 155 posts

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

#11

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.

Can you elaborate on what they are, for the curious?

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

#12

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.

Fwiw we’ve had a lot of success with Golang (graph-gophers/graphql-go w/ dataloader). Running in prod for about a year. Worth noting is that any GQL server implementation not written in JS, will play catch-up to the JS/Apollo counterpart. The JS ecosystem just moves so much faster

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

#13

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.

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

#14
post #2

I've just been trying to get back into elixir recently, myself. I'd done some basic crud 'helloworld' stuff when I first tried about a year into professional development. I've since had the Fortune to spend time learning about cloud native apps, distributed service patterns, and supporting infrastructure (spring cloud, pcf, vanilla k8s, gcp) and now returning to elixir having at least better understanding of what erl…

I almost exclusively learned the basics of Elixir / Phoenix by looking at the source code of https://changelog.com which is at https://github.com/thechangelog/changelog.com.

Major kudos to them for open sourcing their platform. It covers like 50+ common web dev features.

I pretty much skimmed the docs to get the ultra basics, looked at that source while I was building my own app and then asked questions when I got really stuck. Even managed to sneak in some refactoring on their code base a few days into learning Elixir. It's super approachable without much more if you have some type of programming background beforehand.

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

#15
post #2

I've just been trying to get back into elixir recently, myself. I'd done some basic crud 'helloworld' stuff when I first tried about a year into professional development. I've since had the Fortune to spend time learning about cloud native apps, distributed service patterns, and supporting infrastructure (spring cloud, pcf, vanilla k8s, gcp) and now returning to elixir having at least better understanding of what erl…

I am pretty much in the same boat. My resources have been Programming Phoenix first edition. I am now going back and reading Programming Elixir and then re read Programming Phoenix 1.4 and then the GraphQL book by same publisher.

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

#16
> I also find a lot of joy in its pattern matching and its pipe operator. It’s refreshing writing heavily functional code that still approaches the beauty of ruby, and I find that it drives me to think clearly about my code and write fewer bugs as a result.

This.

I use Elixir everyday. While it feels 'refreshing' to use pattern matching, sometimes it gets over-used, as a simple swtich-case statement is easier to read.

Same with pipe operator. I found newbie programmers tend to pipe for the pipe's sake, and write functions just to form the 'shape' of pipe, but the data shape changes are not easy to see and inspect.

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

#17

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.

Dotnet Core is actually really nice as well, I think v3 is right around the corner. Something worth checking out if you're looking into beckend technologies.

I've been using it lately, coming from Node.js for the last few years, and it's been a really nice change.

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

#18

Earlier quoted context omitted.

When would erlang,jvm be preferable over actix.

rust is still figuring out async, so it's not as good a fit as say go or elixir. If you are specifically making a graphql backend, idk why you would anything but node, since it has the most mature ecosystem.

I mean actix just hit 1.0 and I don’t think it impacted them one bit.

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

#20

Good read. Curious about Elixir. Why would one use this over ‘plain old’ Erlang / OTP apart from the Rubyesque syntax, which might appeal to RoR devs?

It's 100% the syntax. It appeals to ruby devs and also I think it's a lot easier to grok in general. But you can write Erlang code directly in an Elixir file, you can use Erlang libraries directly in Elixir, and Elixir compiles to the same BEAM instructions that Erlang does, so there's functionally no difference in terms of capabilities or what happens when they run.
Post reply on HN