Live data from Hacker News

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

schneider.dev

41–50 of 155 posts

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

#41

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 are propagated to you as the consumer of the library because you have to consume the library in a way that satisfies whatever advanced type features they have. So the end result is that to get anything done like make a basic Yesod web app you have to be at an advanced level. I feel i benefitted from learning the structural and type theoretic aspects (monads etc) of Haskell but I also am glad i ditched it after some time because the investment just did not seem worth it anymore after a certain point. Anyway just my perspective, hope its helpful if you find similar difficulties. Right now I’m checking out Scala as an alternative, but i’ve just started so I can’t offer any comparison other than I know it is less rigorous.

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

#42

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 not just syntax. There are semantics differences.

A big one is that Elixir allows rebinding of a variable. Erland does not, which tends to lead to ugly names since in erlang you can't do common reassignment patterns like x = x * someConversionFactor.

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

#43

Does anyone here who is working with elixir professionally have a sense of what kind of mastery is needed to jump into an elixir dev role? I've used it on and off for ~4 years at this point and in a few side projects (most recent one using everything in the title, weirdly enough) but can't really tell if I'm "qualified" to look for a job in it. It's this weird loop of "I've only done something as a hobby so I'm not q…

If you’re looking for an Elixir dev role, we’re growing our team at HIFI and hiring junior and senior engineers in NYC (also open to remote).

We’re building a business management and financial services platform for music creators and rightsholders. Our stack is GCP, Elixir, Typescript and React Native.

Feel free to email me at the address in my profile. Would be happy to chat.

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

#44

Why is Elixir always being paired with Phoenix? Can’t I just have a backend API running on Elixir and a javascript front end to interact with it? I’d prefer a simple React, Postgres, Elixir stack (REP).

I have an app like that, but I found it convenient to use Phoenix anyway as it provides test helpers, a nice router, an efficient template (EEx) compiler with escaping, etc. I just ignore the parts I don't need.

Phoenix LiveView looks super interesting for simplifying this further: https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...

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

#45

Earlier quoted context omitted.

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.

This is not totally true. It’s not 100% syntax. Elixir has one additional and widely used feature: macros. In Elixir, as in Lisp, you can transform your code as a data structure into new code. This is importantly used in Ecto, the de-facto object data mapper in Elixir. It’s also used in Absinthe, a library from the posted link for making GraphQL APIs.

Protocols are also an important feature. `IO.inspect`, `Enum`, etc. are very nice additions.

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

#47

Does anyone here who is working with elixir professionally have a sense of what kind of mastery is needed to jump into an elixir dev role? I've used it on and off for ~4 years at this point and in a few side projects (most recent one using everything in the title, weirdly enough) but can't really tell if I'm "qualified" to look for a job in it. It's this weird loop of "I've only done something as a hobby so I'm not q…

I think for Phoenix it's quite easy to deal with unless the project requires a lot of Erlang/OTP stuff.

If it's just plain old request/response styles website (I think most of the project falls into this bucket) if you can handle other frameworks like Rails or Python, you can handle the same thing really well after some usage. Some basic knowledge of the language/MVC/Ecto would do.

Though there are a lot of React developers already using React but don't know what they are doing. Using React actually requires a good sense of the ecosystem - which set of libraries to use, which pattern to follow etc. Plus some basic concept like state/props/immutability/HOC would do.

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

#48
post #45

Earlier quoted context omitted.

This is not totally true. It’s not 100% syntax. Elixir has one additional and widely used feature: macros. In Elixir, as in Lisp, you can transform your code as a data structure into new code. This is importantly used in Ecto, the de-facto object data mapper in Elixir. It’s also used in Absinthe, a library from the posted link for making GraphQL APIs.

Protocols are also an important feature. `IO.inspect`, `Enum`, etc. are very nice additions.

In general the standard library organization is superb and well laid out. It’s the only language I don’t have to consistently lookup "how do I do X with string", or “Y with a list".
Post reply on HN