Live data from Hacker News

Ask HN: Who regrets choosing Elixir?

news.ycombinator.com

261–270 of 340 posts

Re: Ask HN: Who regrets choosing Elixir?

#261

Earlier quoted context omitted.

> there was no one left who could support an Erlang system. If you have $200k "python engineers" on the payroll who wouldn't jump at the opportunity to do some additional Erlang, maybe it's time to reconsider your hiring practices and that is the real cautionary tale.

Completely agree. I worked at a company on a Common Lisp project where the Python crew refused to learn Common Lisp because they thought it would look bad on their resumes. This should be a litmus test for programmer quality: If they don't want to learn something because it's not "fashionable", they're probably lousy programmers who lack confidence in their own abilities. Do you really want these people working for y…

> Completely agree. I worked at a company on a Common Lisp project where the Python crew refused to learn Common Lisp because they thought it would look bad on their resumes.

They can put only "Python" on their résumés, right?

Re: Ask HN: Who regrets choosing Elixir?

#262

I tried implementing an algorithm for tracking multiple objects based on graph-cuts using Elixir. I was disappointed in the lack of strict typing in the language, since this is one of the things that made me want to try functional programming. In order to tell the type of various method signatures, it seems like you have to go looking at other areas of your program. I’m aware that it’s possible to annotate method sig…

Why would you "try to implement" stuff in a language that is clearly dynamically typed and then be disappointed about lack of types? It's like trying Python and being disappointed about it lacking types. Do you often try languages without even googling for a basic description and then are disappointed because it's not like other programming language or what you expected?

Re: Ask HN: Who regrets choosing Elixir?

#263
post #249

Earlier quoted context omitted.

Well, a Java developer isn't going to want to give up the JVM, their type safety, and great tooling, for a start. I get being interested in Erlang if you're doing Python. But interested in doing Python as a Java dev? Probably not.

Seriously, why doesn't python have a maven equivalent yet? And no fat-binaries. Nor self executing binaries. It's just as old and having em basically just boils down to enforcing conventions. But nope, nothing. There have been attempts by some such as shiv, but really... None are even remotely as usable as maven is.

You could containerize your python. That's like having a fat binary.

Re: Ask HN: Who regrets choosing Elixir?

#265
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…

> there was no one left who could support an Erlang system. If you have $200k "python engineers" on the payroll who wouldn't jump at the opportunity to do some additional Erlang, maybe it's time to reconsider your hiring practices and that is the real cautionary tale.

$200k !

Re: Ask HN: Who regrets choosing Elixir?

#266
post #252
post #232

Earlier quoted context omitted.

Productivity and working knowledge of a tool do not count as rational merits? It takes years to really learn a language; a new framework and language per week is a stupid fad. If I run a Java shop I want a clique of Java devs, not Golang or Rust devs.

There is some truth in this, but less than commonly believed. A "multi cultural", Jack-of-all-trades kind of team, that have a broader knowledge of many tools and techniques but less in depth familiarity with any of them, is more likely to use less features from the languages and tools that they have picked for a few of their strong points only, and less likely to indulge themselves with a level of sophistication tha…

Most of the tools we use are language agnostic - databases, message brokers, containers, kubernetes, etc.

>So I know a Python shop must be a business that sells reptiles, but what does a Java shop sell?

Coffee obviously.

Re: Ask HN: Who regrets choosing Elixir?

#267

Earlier quoted context omitted.

If you're claiming that Erlang is no better at hot-swapping code than "all languages", you haven't seen Erlang's hot-swapping abilities. "All languages" provide you the ability to run arbitrary code, and thus theoretically support hot-swapping, but if you try to put it into practice you'll soon run into real obstacles you hadn't considered that either bite you or at the least make your job a lot harder. Erlang provid…

I have seen it, it is no better than Python's, exactly as I said. Hot swapping Erlang in production is rarely done, and if it is done, it mostly done during debugging, not serving production traffic. I invite you to do a straw-poll on the erlang mailing list.

> I have seen it, it is no better than Python's, exactly as I said.

I'm going to have to call your bluff and ask you to substantiate your claim. Please show where Python provides, as a part of the language and/or the standard library, the equivalents of these Erlang built-ins:

1. Module versioning (via vsn)

2. The ability to run multiple versions of the same module at the same time, transparently and for as long as needed.

3. The versioning (via Module vsn), tracking (via handle_call/3 and derivatives), and migrating (via code_change/3) of State.

4. The dependency tracking and ordering between code updates of multiple modules (via release_handler)

These are the native features that make hot-swapping in production not only feasible, but also powerful and easy. Of course, these are built on top of foundational primitives that are possible in any language, sure, but not all languages (including Python) have these natively available.

----

> Hot swapping Erlang in production is rarely done, and if it is done, it mostly done during debugging, not serving production traffic.

> I invite you to do a straw-poll on the erlang mailing list.

I'm sorry, but this point you're introducing now is unrelated to the discussion we're having, so I'll refuse to respond to this in any way except to remind you of the point we _are_ discussing:

1. adrr's claim: " Erlang was developed for telecommunication systems where you need performance and the ability to hot swap code." https://news.ycombinator.com/item?id=23286646

2. To which you responded: "Erlang's hotswap and Python's hotswap are of comparable power, ie, both are crappy. Being able to do something isn't the same as doing it well.

You can hot swap all languages." https://news.ycombinator.com/item?id=23287624

Re: Ask HN: Who regrets choosing Elixir?

#268
We've been using Elixir for our API server from the start. It's a great language and scales really well. We needed to add a websocket API at some point, and now it's our channel with most throughput. Phoenix handles it fine, and we're still able to triple the throughput comfortably.

The one thing that we struggled with Elixir with is that it's quite hard to find people that know Elixir. For a long time I was the only one doing Elixir in the company, which introduced a bottleneck. That said, when you find someone who knows Elixir they tend to know Elixir (and a bit of infra) quite well.

Re: Ask HN: Who regrets choosing Elixir?

#270

Earlier quoted context omitted.

Seriously, why doesn't python have a maven equivalent yet? And no fat-binaries. Nor self executing binaries. It's just as old and having em basically just boils down to enforcing conventions. But nope, nothing. There have been attempts by some such as shiv, but really... None are even remotely as usable as maven is.

You could containerize your python. That's like having a fat binary.

yes, you can do that. I've been doing that for around 8 years now.

And no, it's not the same. Not even remotely. The only thing that helps with are quick and easy deployments.

The thing which makes maven special is the ease of producing artefacts for deployments, not the final step of starting it up on the server.

Post reply on HN