21–30 of 125 posts
The graph on the homepage says echo2-fasthttp processed almost half the requests that iris processed, but in half the time. Wouldn't that make them approximately equal? I think what it's trying to communicate is the number of requests each framework managed in 500ms, but it isn't clear.
"It’s gonna work good on all devices." Don't they mean work well?
Anyway, it's acceptable American English.
Comments empty and wrong.
The performance comes from using https://github.com/valyala/fasthttp instead of the stdlib net/http. From this project's FAQ: >Why creating yet another http package instead of optimizing net/http? Because net/http API limits many optimization opportunities.
And then you got your database and you speed is comparable to the rest of the world :) What I think could work is a pure in memory database with server combination. Something like redis for websites.
The selling point of Redis for me has been its simplicity. It has a fairly small set of features in comparison to other databases, yet extremely powerful.
[0] - http://oldblog.antirez.com/post/redis-persistence-demystifie...
That graph is really confusing, is the x axis a progression of processing times from 0 up to ~1000ms? If so then wouldn't it mean that Echo-2-fasthttp has nearly as good requests/second?
There's a bit more detailed bench here: https://github.com/smallnest/go-web-framework-benchmark
Could someone clarify: why is Go faster than say Python? And if the answer is just that it's a lower level language and therefore has less overhead, why not just use C?
That graph is really confusing, is the x axis a progression of processing times from 0 up to ~1000ms? If so then wouldn't it mean that Echo-2-fasthttp has nearly as good requests/second?
That graph is really confusing, is the x axis a progression of processing times from 0 up to ~1000ms? If so then wouldn't it mean that Echo-2-fasthttp has nearly as good requests/second?
Earlier quoted context omitted.
And then you got your database and you speed is comparable to the rest of the world :) What I think could work is a pure in memory database with server combination. Something like redis for websites.
I use Redis as the primary and only database. This results in quite large savings in terms of server infrastructure since memory has never been cheaper than it is today and the minimal amount of resources Redis consume in relation to the massive amount of throughput it provides. Additionally, it has data persistence reliability on par with Postgres and other battle-tested databases[0], so couldn't be happier about th…
Not only is this page riddled with typos that lead me to doubt the quality of the code, the concept of a framework is fundamentally complex and at odds with the goals of Go.
I'd argue that at least the author tried to write a real documentation, which 95% of Go library authors don't do.
> the concept of a framework is fundamentally complex and at odds with the goals of Go
The famous "You don't need that with Go ™ ".
It's more like Gophers hate the word "framework","dependency injection" and "orm". It's hardly a framework, it's a router and a middleware stack.
Instead of being enthusiastic about others using their language, like in any other community, Gophers like to hate, shame, mock other people because they didn't do things "the Go way", whatever they think it is. It's one of the most toxic community I have ever seen.