Hacker News Reader

Comment by strokirk | Hacker News Reader

It annoys me how much Elixir zealots proselytize the language as the the objectively best thing since sliced bread, and all other languages are worse. But it's a well written article.

Good on them for finding Elixir useful, but none of the benefits they talk about seem very compelling for me. Most of them are available as table stakes in other languages (rerunning failed tests as an USP of mix test, really?), or very situational/subjective benefits. I find the import system in Elixir to be very opaque, making it hard to know where a function is coming from after it's been aliased and use:d. I subjectively find explicit import statements much clearer when debugging code.

The final drops for me are the missing explicit return statement, and the extraordinarily bad tracebacks on error. If I could I would excise Elixir from our company.

View on HN

Regarding explicit vs implicit imports, elixir supports both. However explicit aliases are preferred both for clarity and compilation speed. Perhaps discuss with your team why they are (seemingly) preferring to import rather than alias?

Hahaha maybe so, but have you met Go devs? The cult of "simplicity" and static typing fundamentalism is just a reaction to JavaScript IMHO. What these folks don't realize is that langs like Python can do everything including static types, and was always strongly typed, having never allowed bad casting edge cases like JS.

I will also add that goroutines (and actors and other first-class concurrency constructs) built into a language doesn't really help with web startups that aren't targeting large scale consumer traffic or systems level apps, and even if it did, multiprocessing GIL languages has never been an issue. It's a cool feature for sure, but language fundamentalism is just a way for insecure devs to feel cooler.

Yeah, I mean, why would you want concurrency primitives when you can spawn a thread, or do mutexes, or do locks at the db level, or use redis as an actor, for when, for instance, you want to allow users to upload N simultaneous files, but have a limit by user plan to 5 maximum uploaded files, or process N CSVs or excel files in parallel and broadcast the changes to all admin accounts, or not allow multiple simultaneous edits to a resource. It's just more sane to rely on 3 or 4 moving pieces outside of your environment to achieve it.

In fact, I think you should go pitch this idea to all OSes developers, nobody is doing more than one thing at any given point in time, so clearly multitasking is unnecessary cruft, pthreads, selects, etc just cater to insecure devs that want to feel cooler and pretend they're not in the stone age of computing anymore.

The missing return statement has never been a big deal in my experience. In part it's absorbed by pattern matching (multiple definitions for the same function) and in part by "let it fail."

Tracebacks are not so bad but they tend to be useless when the cause of an error is in a different process than the one that failed. I know that my GenServer failed at line x with data y, z but I don't know what sent that x to the GenServer. I have no idea if there is a way around this except extensive logging.

> I know that my GenServer failed at line x with data y, z but I don't know what sent that x to the GenServer. I have no idea if there is a way around this except extensive logging.

Ah, you were using casts instead of calls. Use calls as much as possible, even if you always send back :ok. This needs to be documented as part of best practices.

IMO pattern matching often makes the code harder to read, especially with deep destructuring spanning multiple lines. Could be our codebase, but writing code prolog-style has always made it neigh-unreadable to me.

Reply on news.ycombinator.com