Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The sooner you start smacking people with tribal knowledge, the sooner many people start to back away slowly.

I used to interview ex-coworkers. I don't do it as much anymore because it gets old/depressing and the answers tend not to change that much.

If, for the purposes of thinking about turnover, you look at a former colleague as an 'aggrieved party', we are generally somewhere in the neighborhood of mediocre at agreeing that certain things were the 'final straw', and work backward through that to actions to increase retention.

One of the things that interested me about these conversations was that people tend to work chronologically backward through many of their complaints. But what was surprising was that some people would go all the way back to their first weeks. To the first straws. The warning signs they ignored. In a way this is not unlike talking to someone who just broke up with a romantic partner.

And while their ex may realize that his/her problems started back with some early inconsiderate behavior that snowballed, and resolve to 'do better next time', I rarely see companies do this, unless I instigate it.

Point is, these petty slights stack up, and can become a big part of someone's narrative for abandoning you (often in a huff). First impressions are important, and you dismiss them at your own peril.



What? GP's response is terse but not impolite, and explaining what an abbreviation means is a far cry from "smacking people with tribal knowledge", it's just table stakes explanation in a field which requires precision.

The only reason modern computing got where it is today is by standing on the shoulders of giants. If we go back and re-litigate every naming decision of the past several decades just to make newcomers feel welcome, all progress will slow as we collectively devolve into continuous bikeshedding.


FWIW I thought the response was entirely fine and it wouldn't have occurred me to take offense at it.

(I actually googled what "gen" in "GenServer" was supposed to mean before posting, because I couldn't remember but knew it wasn't "generate", and couldn't find an answer, including in the docs for GenServer)

[EDIT] to clarify, I failed to find the answer in any of the Elixir docs for GenServer. Evidently I should have looked at Erlang.


Version 1.0.4, first paragraph:

https://hexdocs.pm/elixir/1.0.4/GenServer.html#content

`The advantage of using a generic server process (GenServer)`

current release (1.11.4), first paragraph;

https://hexdocs.pm/elixir/1.11.4/GenServer.html#content

`The advantage of using a generic server process (GenServer)`


TIL: ignore elixir-lang.org, go to hexdocs.


Elixir-lang.org > docs > elixir takes you straight to hexdocs.


I'm talking about the name GenServer, not brobinson's response.

There is the corollary:

    If we have not seen farther, it is because giants were standing on our toes.
There's a huge degree of cognitive dissonance on these issues. Just because something had a reason in the past doesn't mean we have to keep doing it forever. Also "nobody understands" why people keep re-inventing wheels. It's not all hubris, at least not all the time. It's also declaring open season on those past compromises, especially the ones people bump into immediately. Especially the ones the current maintainers immediately get defensive about. Technology dies for a lot of reasons, but the apologists never seem to grasp that the apologies are a stopgap. They explain the pain, they don't cure it.

Believe it or not, I'm pro-Elixir. It's just that as I learn any new technology, I start filling out proverbial bingo card boxes for the things I can predict the next person will complain about. Is that a bit cynical? It could be, but it also serves as my todo list for when someone makes an offhand comment about how you really don't have to do this dumb thing, you could use this library that does it for you. Now my coworkers either don't have to worry about that or I have a suggestion when they do.

Turns out when people are in pain, they appreciate sympathy a lot more than they appreciate being gaslit about how it's just their poor sense of history. Their blatantly implied selfishness.

GenServer could use a new name. I think we forget sometimes that you can rename old things by giving them a second, better name and phasing out the old one. I don't think there's anything seditious in that statement.


I am not very deep on Elixir, but I have heard of some substantive complaints about GenServer as a specific implementation and the cultural effects of the community say "just use GenServer" which shuts down discourse around why it might not be appropriate or at least optimal for all the cases it's recommended. We should absolutely have those discussions. I'm just not sure how many problems are solved by picking a better name.


I think the community typically says "don't use genserver" more than "just use genserver"


I've been using Elixir for 4 years, it pays my bills and I generally like it. GenServer could be a misleading name (it never occurred to me) but the real mess is the bag of handle this / handle that function names. They follow the conventions of Erlang [1] but Elixir's developers could have cast some syntactic sugar on top of it. The real name of those functions is in their first argument. handle_* is mostly noise.

[1] https://erlang.org/doc/man/gen_server.html


Syntactic sugar is of course another form of abstraction and so you have to balance developer ergonomics with that added complexity. As you point out, Elixir's `GenServer` is a fairly simple wrapper module over Erlang's own `gen_server`. As new versions of OTP are released, the maintainers of the Elixir language must also update their own abstractions over those underlying Erlang libraries. It also creates a niche disparity between Erlang and Elixir which some Erlang developers might find superfluous. Coming from Erlang, it's easy to appreciate the syntax of Elixir even if it means getting over some old habits. Perhaps changing the names of foundational parts of the standard library would be less appreciated by those already familiar with OTP, and feel as if the mental overhead is being shifted to those developers rather than simply being ameliorated for developers who are new to the platform.

Designing a programming language is hard, especially when building on top of a 35 year old language like Erlang. As is often the case: if engineers could change the past without breaking everything in the present, we would have already done it. :)


They did the right thing if their goal was to move Erlang developers to Elixir. Not so much if they aimed to onboard Java or C++ developers. If they did, GenServer had to look like a Class like and they would use { } instead of do end. Strangely it seems that they aimed to Ruby developers (like me). That's why they picked do end and similar names for modules and functions. But Ruby developers wouldn't mind a GenServer looking like a class with proper function names instead of atoms in argument lists.


if you don't mind a bit of boilerplate, I use this pattern, it avoids syntactic sugar and achieves what you are looking for:

https://www.youtube.com/watch?v=HA4h0cajgaA




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: