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.