Go is just too different to how I think: when I approach a programming problem, I first think about the types and abstractions that will be useful; I think about statically enforcing behaviour; [..]
This kind of says it all to me though. I don't "approach programming problems", or at least that's not how I see building something to solve a real problem. I won't spend days philosophising about how to "best" solve this particular subset of the problem, but instead get something out that works and improve as we go along and where it actually matters for those using the product. I'm sure that can be done in Haskell, but it doesn't seem that's how the author thinks about things.
and I don’t worry about the cost of intermediary data structures, because that price is almost never paid in full.
Yet the author does, explicitly, worry about it. There's a whole paragraph about it and this tidbit in the conclusion. He relies on Haskell's lazy nature in order to not have to worry about it but refuses to rely on Go's compiler and garbage collector for similar intelligence (i.e it not mattering) and therefor decides not to split up a function, which he would've done in Haskell. And there's also no proof that the intermediary structure would've mattered at all to the end user. To me this comes right back down to "approaching programming" over building solutions.
The link is pointing to the old repo in the Mondough org (from before they renamed to Monzo). Here's the current and source repository: https://github.com/monzo/typhon.
Unfortunately the README is void of any information and the godoc doesn't have usage examples either. Or a rationale for how this is better/different compared to other RPC frameworks. Or some benchmarks...
I'm not convinced I find the first example more readable though:
I'm reading this as "assert that the check that err is nil passed". It certainly reads like a sentence but `if err == nil` seems much more idiomatic, is shorter, to me is also easier to write and conveys the same meaning.
That said, 10/10 for having an actually useful README with examples I can work from, and get a feel for what this is supposed to do and how it's supposed to work.
My conclusion from all this seems to be that if you're running a likely scenario's (hello world is unlikely to be a production service) the benchmarks of frameworks showing how fast they are, are largely irrelevant. The second a database got involved the whole equation changed and I'd venture a guess that if a similar scenario were tried in which it had to query a 3rd service before it could respond you're get similar results as to the database setup.
However if you can answer everything directly from memory the Python-Japronto combination might prove interesting. I'm also curious how much of that standard deviation is caused by Gin vs. something that Go is doing. Would be interesting to rewrite that in Chi and FastHTTP too and see if you'd get similar results.
As interesting as the article is though, their conclusions section baffles me a bit. It seems to be disconnected from the rest of the article.
1. Where does the conclusion comes from that they should probably use Elixir for I/O intensive services?
HTTP is I/O for one and their simulation suggests Go achieves better throughput. If we're talking reading/writing files then there doesn't seem to be any data presented to support that conclusion.
2. I'm also failing to understand their general conclusion:
> In most scenarios, you can achieve the exact same end result with Python as you do with Go. With Python, you’ll probably be able to ship far faster, and have more developers available.
Looking at their benchmarks Go seems to achieve a much better result than Python in real world. So which "most scenarios" are we talking about then? The claims about being able to ship faster is one I find doubtful, especially based on how annoyingly complicated it can be to deploy a Python app because of how dependencies aren't packaged up. If this is about how easy it is to write Python, a lot of that is depending on those writing it. Having more developers available is possible but some kind of metric to back that up would be nice.