4 ms·

> Have you developed in Erlang? Yes. > Erlang has the right abstraction There is no right abstraction. If we can't minimally agree that there are trade offs

> Have you developed in Erlang? Yes. > Erlang has the right abstraction There is no right abstraction. If we can't minimally agree that there are trade offs at play here, then we can't have a productive conversation. > and avoid ever "handling" errors I want to explicitly handle my errors. Just because you had great internal progress does not mean you arrived at some objectively correct solution. It obviously works well for you, but everyone is not you and not everyone has the same requirements or preferences as you.

saurik 12y ago
The arrow I am providing for progress is one towards abstraction and automation; so, fine: we are right back to where we were before, with you making an argument that is of the exact same form as those people from C, Go, and Java who argue against adding abstraction and automation to keep things explicit and transparent, the people you were so painfully opposed to being lumped together with, and you seem to have exactly as little concrete rational as they do for making that "tradeoff". It isn't clear there is any tradeoff in play here, and you haven't tried to demonstrate one. My argument is "given that there is absolutely no demonstrated benefit to doing so, and even some clear downsides (performance of normal successful code), being forced to litter my code with tons of boilerplate--something you can clearly see if you glance almost anywhere in the code for Cargo--is a major and depressing step backwards". Your argument seems to still be "I don't want that much automation, I like things being explicit, and of course you should look again the comments from pcwalton you already responded to that complain about Java (really just Java) being slow"... :/.
- burntsushi 12y ago
  Explicitness has benefits. Honestly, please just leave me alone and stop twisting my words. We can't even agree that there are trade offs involved here. There's no point in continuing.

saurik 12y ago

The arrow I am providing for progress is one towards abstraction and automation; so, fine: we are right back to where we were before, with you making an argument that is of the exact same form as those people from C, Go, and Java who argue against adding abstraction and automation to keep things explicit and transparent, the people you were so painfully opposed to being lumped together with, and you seem to have exactly as little concrete rational as they do for making that "tradeoff". It isn't clear there is any tradeoff in play here, and you haven't tried to demonstrate one. My argument is "given that there is absolutely no demonstrated benefit to doing so, and even some clear downsides (performance of normal successful code), being forced to litter my code with tons of boilerplate--something you can clearly see if you glance almost anywhere in the code for Cargo--is a major and depressing step backwards". Your argument seems to still be "I don't want that much automation, I like things being explicit, and of course you should look again the comments from pcwalton you already responded to that complain about Java (really just Java) being slow"... :/.

burntsushi 12y ago
Explicitness has benefits. Honestly, please just leave me alone and stop twisting my words. We can't even agree that there are trade offs involved here. There's no point in continuing.