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

Ask HN: Who regrets choosing Elixir?

news.ycombinator.com

Post reply on HN
Print view View original

111–120 of 340 posts

Re: Ask HN: Who regrets choosing Elixir?

#111

Post by eshyong »

nicoburns wrote: post #107
as-j wrote: post #92

TL;DNR, use a language your company can support. It doesn't matter how suited to the job a language is, if it's single Engineer or small team, what happens when they move on? How do you support it? Who's on call? Not Elixir, but a cautionary tale from our Erlang project. ~8 years ago a our IoT backend was written in Erlang, this was the early days of IoT, so sure it made sense as a technology, could scale well, handl…

Why not get your existing engineers to learn erlang if you have such a need?

Probably cost of training. You'd have to hire consultants to teach best practices and that could cost significantly more than hiring a new engineer. Plus there are other risks to maintaining two codebases in different languages.

Re: Ask HN: Who regrets choosing Elixir?

#112

Post by dnautics »

pavel_lishin wrote: post #97
mapcars wrote: post #30

Earlier quoted context omitted.

>when using keyword lists for function options Proplists should be replaced with maps pretty much everywhere. >Also mocking was difficult in tests Interesting, what exactly was difficult? You just replace one function with another.

> Interesting, what exactly was difficult? You just replace one function with another. I'm not the person you're asking, but iirc, that replacement is global - so once you replace function/module X with MockX, you can't test X itself, nor anything else that relies on X.

This is 100% correct, and a very huge pain point, and why you're supposed to use Mox, which solves that problem (arguably in a more conceptually "correct" fashion than ad-hoc Ruby Mocks). Admittedly there is a very steep learning curve, but it's worth it, because once do it you start to be able to do things you can't do in any other PL (not even erlang).

It's a pity that the elixir community doesn't make this clearer, because I'm seeing "not being able to Mock" be a common complaint.

Re: Ask HN: Who regrets choosing Elixir?

#113

Post by rahimnathwani »

treis wrote: post #51
brenden2 wrote: post #23

Earlier quoted context omitted.

Phoenix is the closest, and while it's not exactly a Rails clone, it provides most of what you need to get started. It's similar to Rails in that there's a CLI to generate code, and frameworks for unit testing, DB modeling, templating, etc. Where Phoenix really shines is its support for fancy stuff like Websockets and distributed messaging in your backend. Trying to do these things in Rails leaves much to be desired.

I mean more stuff like Devise for authentication, Apartment for multitenancy, ancestry for hierarchical data, etc. Seems like every common problem has a gem that solves it. Does Elixir/Phoenix have equivalents?

Triplex / Apartment Coherence / Devise ExAdmin / ActiveAdmin

Re: Ask HN: Who regrets choosing Elixir?

#114

Post by marcosdumay »

brudgers wrote: post #64
tonyarkles wrote: post #25

Right tool for the right job, I think. I’ve had absolutely wonderful experiences with Elixir doing web apps (both LoB style and SaaS style). Probably the best one, and it’s such a canonical example, is a group chat app using Websockets. It just feels so good, and with libcluster, multiple nodes in K8s can autodiscover and join each other. No problems at all having chats where the members are connected to websockets o…

let it crash != robustness not required Let it crash is an engineering design for systems large enough that statistically unlikely failures occur regularly. Like a data center or the original use case, telephone switch centers. Even if let it crash worked, it seems philosophically inappropriate for a drone controller.

I see no incompatibility with a drone controller if you have enough redundancy or can restart services fast enough for it to not be a problem (probably 1 second is still ok).

What is completely incompatible with disposable workers is complex numeric processing. Unless you can segment it with small non-communicating unities, of course. That's the kind of application that asks for a low level language.

Re: Ask HN: Who regrets choosing Elixir?

#115

Post by jasonlotito »

nicoburns wrote: post #107
as-j wrote: post #92

TL;DNR, use a language your company can support. It doesn't matter how suited to the job a language is, if it's single Engineer or small team, what happens when they move on? How do you support it? Who's on call? Not Elixir, but a cautionary tale from our Erlang project. ~8 years ago a our IoT backend was written in Erlang, this was the early days of IoT, so sure it made sense as a technology, could scale well, handl…

Why not get your existing engineers to learn erlang if you have such a need?

Because "learning" Erlang is like learning any language. Sure, you can learn the language in short period of time, but really being able to professionally support a production level app to the level needed will take a long time and a lot of practice. And that practice isn't a week long course where you suddenly learned Erlang and then that's it. You aren't working with Erlang any more.

You don't need someone "learning" Erlang. You need someone who works with it.

Re: Ask HN: Who regrets choosing Elixir?

#116

Post by ajkjk »

eshyong wrote: post #111
nicoburns wrote: post #107

Earlier quoted context omitted.

Why not get your existing engineers to learn erlang if you have such a need?

Probably cost of training. You'd have to hire consultants to teach best practices and that could cost significantly more than hiring a new engineer. Plus there are other risks to maintaining two codebases in different languages.

You have to hire consultants to teach best practices?

Re: Ask HN: Who regrets choosing Elixir?

#117

Post by shreddit »

nicoburns wrote: post #107
as-j wrote: post #92

TL;DNR, use a language your company can support. It doesn't matter how suited to the job a language is, if it's single Engineer or small team, what happens when they move on? How do you support it? Who's on call? Not Elixir, but a cautionary tale from our Erlang project. ~8 years ago a our IoT backend was written in Erlang, this was the early days of IoT, so sure it made sense as a technology, could scale well, handl…

Why not get your existing engineers to learn erlang if you have such a need?

One does not simply learn erlang

Re: Ask HN: Who regrets choosing Elixir?

#118

Post by rorygreen »

hartator wrote: post #102

I’ve played with Elixir/Phoenix a little bit and was not very happy with a few things: - Debugging is hard. You can’t throw a REPL wherever your want in your code and pipe states are hard to inspect. - Serving static files in Phoenix is oddly super hacky. - Deploy is hard. Mostly by the lack of support out there in term of documentation and services.

> You can’t throw a REPL wherever your want in your code

In my experience, I found I could throw a `require IEx; IEx.pry` pretty much anywhere in the code to get a REPL. This seemed like a unique superpower of Elixir to me. Where have you found that this isn't possible?

I agree with the pipe states point.

My main complaint with Elixir is that I'd discover really stupid mistakes with run time errors. The sort of things a bunch of other languages I've used would preclude at compile time. I never dug into more advanced debugging or Dialyzer though.

Re: Ask HN: Who regrets choosing Elixir?

#119

Post by PragmaticPulp »

as-j wrote: post #92

TL;DNR, use a language your company can support. It doesn't matter how suited to the job a language is, if it's single Engineer or small team, what happens when they move on? How do you support it? Who's on call? Not Elixir, but a cautionary tale from our Erlang project. ~8 years ago a our IoT backend was written in Erlang, this was the early days of IoT, so sure it made sense as a technology, could scale well, handl…

Your comment was so spot-on that I suspected we worked at the same company for a minute.

Erlang / Elixir are languages that are easy to begin learning, but difficult to master. In our case, the team was able to get the basics up and running quickly, but the service became increasingly difficult to manage as our product requirements expanded beyond the strengths of the Erlang ecosystem's core competencies.

In our case, the original team of developers was excited to write a greenfield service in Erlang, but much less excited to maintain and scale it long-term. Some of them used their experience to speak at Erlang conferences, which led to them being recruited away by companies who were desperate for Erlang developers to maintain their legacy code after the core team left. Ironic.

At first we tried to train existing engineers on Erlang. Doesn't work. Not because Erlang is bad, but because people don't want their companies changing the direction of their career development just to support someone else's legacy project that requires an on-call team to support.

So your two options are: Hire at least 2, preferably 3 Erlang engineers for the reasons discussed above. Harder than it sounds, because AFAICT there are a lot of companies with 2010-era Erlang backends that made sense at the time but now require dedicated maintenance engineers.

Or you can rewrite it in a more common language, which is the route we chose. Rewrites are a difficult decision for well-known reasons, but ultimately it was the correct choice. Being able to drop 10+ engineers into a project as needed is a huge accelerator compared to funneling 100% of your work through the 2 Erlang gurus in the corner who maintain a codebase that no one else wants to touch.

Re: Ask HN: Who regrets choosing Elixir?

#120

Post by dnautics »

hartator wrote: post #102

I’ve played with Elixir/Phoenix a little bit and was not very happy with a few things: - Debugging is hard. You can’t throw a REPL wherever your want in your code and pipe states are hard to inspect. - Serving static files in Phoenix is oddly super hacky. - Deploy is hard. Mostly by the lack of support out there in term of documentation and services.

1. IEx.Pry, if you are used to ruby's pry. Pipe states are extremely easy to inspect:

    abc
    |> foo()
    |> bar()
to

    abc |> IO.inspect(label: "a")
    |> foo() |> IO.inspect(label: "b")
    |> bar() |> IO.inspect(label: "c")
If you use vscode, this user snippet will inject this (with line numbers as labels) when you type "ins ", which can be used to great effect with multiline cursors. Since line numbers are usually the same length in any given block of code, it's equally easy to ninja those IO.inspects out with the delete key. https://gist.github.com/ityonemo/00875891748bed3ee68e5f1b75c...

2- agreed

3- Mix releases have solved 80% of this problem, for me. Since it's trivially extensible, I do a series of compile-time checks, include verifying that the current branch is on master and correctly git-tagged; and then uploading to Amazon S3. I haven't done this yet, but it's going to eventually trigger an automated blue-green deploy.

Post reply on HN