Thank you for the explanation. I think it makes sense somehow, however, and high likely because I've never dealt with errors in that way, the _encounter error, crash, restart, continue_ workflow seems a bit awful to me :)
The Haskell solution seems really nice. I've only used Haskell for pet projects and it's one of my favorites languages (though I don't have any proficiency with it,) so thank you for teaching me something else about it.
Ok, verbosity I agree. That doesn't have anything to do with being easy or not, I think. I might be wrong. Verbosity can be a pain. Even after reading Rob Pike's article on "Errors are values" [1], I agree with you that the solution is still verbose.
Those numbers you gave, even when you said they're estimates, still seems like made up numbers. I've never used Elixir, so if you could point me to an example so I can be more informed, I'll be grateful :) but also I've read some Go programs (not many, I'm not an expert) and it didn't seem to me that 70% of the code is dedicated to error handling.
Note that I'm not defending Go's position on error handling, I'm asking about error handling in general, what does people mean with "easy way to do it".
I've never really understood the "no easy way to handle errors" complaint. I'm not saying it is easy, nor that it isn't verbose (hell, it is super verbose!) but I'm seriously asking: what would be an easy way to handle errors? I'm not asking about how to do it in Go, just how to do it in any programming language.
To me errors are very special constructs, is not a typical return value, as for example a method returning true or false whether the arguments are valid or not, so I expect errors to be something similar (at least semantically) as exceptions in other languages, and in that case, that is, return values that should be deal with in a certain special manner, so I don't expect to deal with them in an "real easy way"™, but in a very conscious and deliberated way.
As the commit author here, I must confess that it was so painful to write that story that I had to stop coding and go out for a walk. I was devastated...
I use it as the only database in most of the projects I've work at my company, using Ohm [1] as our ORM. Usually we don't have use cases with ad hoc queries like `name LIKE '%Smith'`, so it serves our purposes very well. When we need something like that, we integrate with something like Elasticsearch.
I agree with you, having the ability to script everyday tasks is awesome, though however in the case of the ssh wrapper it might be a little overkill, given that you can achieve the same (and more) with a ssh_config file [1] [2]. I would particularly recommend the ControlMaster option.
I'm not bashing against Haml, all that I'm saying is that is not necessary. Lately Slim also has become quite popular, so that would involve also having the Slim version. And in the future it will be something different, but as long as HTML remains as the lingua franca of the web, then there's no really need.
I used Haml in the past, and I understand it's popular nowadays mostly because of Rails, but I hardly think it's widely-used. Just to name a few that use HTML or a template engine of their own: Blogspot, Tumblr and Wordpress, and these are much more widely-used than Haml.
1: https://prometheus.io/docs/prometheus/latest/configuration/c...