
Iris: Fast back-end web framework for Go - chenzhekl
http://iris-go.com/
======
StreamBright
Any time I see a chart about web server performance without displaying the
corresponding error rate and latency numbers I start to think that the author
does not understand the performance aspect of HTTP services entirely.

~~~
ricardobeat
Error rate? I believe when doing http benchmarks it is assumed to be zero.

------
mappu
The performance comes from using
[https://github.com/valyala/fasthttp](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._

~~~
Bombthecat
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.

~~~
Svenskunganka
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 that.

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...](http://oldblog.antirez.com/post/redis-persistence-
demystified.html)

~~~
qaq
"it has data persistence reliability on par with Postgres" if we pretend
transactions do not exist and postgres is running in some non-default config
then maybe, but we don't need to pretend.

~~~
calcifer
Redis has transactions as well.

~~~
qaq
yes and if you set appendonly yes appendfsync always you will get about +/\-
PG write performance without all the features Now I know 0 production projects
using these Redis settings and I would argue it's not intended use of Redis
same way as running PG with fsync = off is not generally what you want to use

~~~
mbrock
Why isn't it intended use? And are there actual problems with it even if it
isn't intended use?

~~~
jpgvm
It's not intended use because fsyncing every write to disk makes it inferior
to every datastore designed to fsync every write. See here PostgreSQL.

For read performance if your dataset fits in memory PG is just as fast as
Redis.

The main attraction of Redis is in-memory writes with async persistence.
Trading durability and availability for the increased performance. If you give
up this then there is precisely 0 reasons to choose Redis over PostgreSQL.

~~~
anarazel
> The main attraction of Redis is in-memory writes with async persistence.

FWIW, you can have that in postgres as well, cf. synchronous_commit = off

> Trading durability and availability for the increased performance. If you
> give up this then there is precisely 0 reasons to choose Redis over
> PostgreSQL.

As a PostgreSQL developer, I'd say that performance / latency / jitter can
still be reasons to choose redis over postgres. The per-read overhead in redis
is often a good bit lower than in postgres, and there's less variability in
response times.

------
onion2k
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.

~~~
Dzugaru
Wouldn't trust programmers, who make illogical graphs like that one :D

~~~
xaduha
I wouldn't trust any web framework that isn't yet on
[https://www.techempower.com/benchmarks](https://www.techempower.com/benchmarks)

It might not be perfect, but it's common ground.

~~~
weberc2
Cool site. FWIW, fasthttp powers iris, and it's in these benchmarks (and doing
very well at that!).

------
gelatocar
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?

~~~
mkishi
It is confusing. They meant the benchmark used a 500ms "workload" (sleep) per
request handler -- x isn't really an axis.

------
rattray
Features:
[https://kataras.gitbooks.io/iris/content/features.html](https://kataras.gitbooks.io/iris/content/features.html)

(seems to be missing a data/SQL/ORM layer)

Usage docs for rest api:
[https://kataras.gitbooks.io/iris/content/render_rest.html#us...](https://kataras.gitbooks.io/iris/content/render_rest.html#usage)

~~~
piotrkubisa
Not including an ORM layer does not decrease "value" of this framework,
because you can attach such lib on your own. In Go the you are very flexible
to set up a "a place where data will be stored/queried" \- there is fabulous
database/sql (or additional layers like lib/pq [1]) which is great for many
use cases; also orm-like solutions like gocraft/dbr [2]; oh, I also should
mention Gorm [3] or Bolt [4]. Setting them up is really easy in any Go web
frameworks because (almost) all database modules rely on abstraction from
stdlib.

[1] [https://github.com/lib/pq](https://github.com/lib/pq)

[2] [https://github.com/gocraft/dbr](https://github.com/gocraft/dbr)

[3] [https://github.com/jinzhu/gorm](https://github.com/jinzhu/gorm)

[4] [https://github.com/boltdb/bolt](https://github.com/boltdb/bolt)

~~~
ptman
Isn't lib/pq more like a driver that's used through database/sql than an
additional layer ?

~~~
piotrkubisa
Indeed. Thank you for pointing this out.

------
oneloop
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?

~~~
andkenneth
Go has high level constructs like python, C# or Java. However, it compiles
down to machine code directly, like C. This is much faster than C# or Java,
which compile to an intermediate interface (CLR and java bytecode
respectively, which then run in a VM), and miles ahead of Python, which
interprets from the source every single time the program is run.

The closest language to go would probably be C++, and the language designers
were quoted saying the main driving force behind go was to replace C++ due to
it's complexity.

~~~
pcwalton
> This is much faster than C# or Java, which compile to an intermediate
> interface (CLR and java bytecode respectively, which then run in a VM)

No. Both C# and Java use JITs, and their JITs have been carefully tuned to
focus on hot spots. By not having a JIT, Go (in the 6g/8g/gccgo
implementations) _loses_ some important optimizations that are very helpful
for making virtual-heavy languages like Go faster. JITs enable on-stack
replacement, bailouts, and self-modifying code, which enable speculative
devirtualization and (polymorphic) inline caching, just to name two
techniques. These are very important optimizations that generally you can only
get reliably in an ahead-of-time setting with profile-guided optimization,
which Go 6g/8g don't have (and PGO is kind of a worse version of what good
JITs do anyway).

The true benefits of AOT are reduced startup time and a greater tolerance for
slower compilation, allowing for more sophisticated compiler
optimizations—instruction scheduling, alias analysis, range analysis, etc. But
Go 6g/8g are focused on fast compilation and omit most of those optimizations
anyway.

~~~
ngrilly
> By not having a JIT, Go loses some important optimizations that are very
> helpful for making virtual-heavy languages like Go faster.

How does Rust work in this regard? By avoiding virtualization, and compiling
each function to many specialized variants corresponding to each possible
permutation of input and output types?

~~~
eddyb
With generics, yes, like C++ templates: each combination of parameters results
in one instance.

However, you can opt into using trait objects instead, which do use virtual
calls.

~~~
ngrilly
Is pcwalton saying that a JIT compiler is more adequate for a "virtual-heavy"
language like Go (to use devirtualization with inline caching and bailout),
and an AOT compiler is more adequate for languages like Rust and C++ that
mostly use code specialization?

~~~
kibwen
It's not quite as clean-cut as that, though it is self-evident that optimizing
at runtime (e.g. JIT) is the only recourse for optimizations that are
otherwise reliant on runtime information (e.g. dynamic dispatch/virtual
calls). Go does have an advantage over Java in that it prefers static
semantics (pcwalton's assertion that Go is "virtual heavy" should likely be
taken as relative to Rust/C++), so has less to benefit from devirtualization,
and thus less of an argument to go the JIT route (which would take monumental
engineering effort).

I believe pcwalton's points are that 1) running in a virtual machine does not
imply that a language is slow (though I bet he'd agree with you that JIT
introduces substantial memory overhead), and 2) Java, specifically, is not
slow, thanks to a highly-tuned JIT.

~~~
ngrilly
Thanks! That's exactly what I wanted to know.

------
yeonsh
Discussed on reddit before and I found that Iris uses caches to speed up.

[https://www.reddit.com/r/golang/comments/4a8yit/is_this_the_...](https://www.reddit.com/r/golang/comments/4a8yit/is_this_the_fastest_go_web_framework/)

------
znpy
There was a discussion about Iris on the github issue tracker of Gin, another
framework, dated March 13 2016:

    
    
       https://github.com/gin-gonic/gin/issues/560
    

Some benchmark were made too.

~~~
benguild
Thanks for posting. I was wondering how this compared to Gin.

------
tapirl
why (and how) comparing web frameworks to httprouter, it is just a router.

------
carlosdp
That's the wrong type of graph for that data... should clearly be a line
graph.

------
anilyeni
nice site to know the other frameworks.

------
OriginalPenguin
"It’s gonna work good on all devices."

Don't they mean work well?

~~~
lucasp82
The project creator is not a native English speaker. Let it go.

------
stirner
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.

~~~
spriggan3
> Not only is this page riddled with typos

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.

~~~
stirner
I didn't mean to hate, shame, or mock anyone. I would rather that programmers
who create complex antipatterns stay in other languages that encourage them,
and if light critique has that side effect, so be it.

~~~
codezero
I'm sure the author would love your help fixing up the typos:

[https://github.com/iris-contrib/website](https://github.com/iris-
contrib/website)

I just submitted a PR to fix a few minor issues. In general, the grammar
issues here are really minimal and the page seems to communicate the project
and its goals very clearly without being too distracting.

I didn't find any explicit typos, like misspelled words, but I didn't look
that hard either, hopefully you can help out!

~~~
stirner
Really, the typo thing was not the main point of my original comment, it was
just an aside. I'm sorry to anyone I have offended.

I mainly take issue with the proliferation of Go frameworks, especially HTTP
frameworks. Frameworks are an antipattern and there are already a huge number
of HTTP frameworks that are all incompatible and reimplement the same
functionality. I don't think this is useful for the language and in fact think
it hurts it.

~~~
codezero
I'm curious, what makes you think frameworks are an antipattern in Go?

What is fundamentally wrong with creating a framework with specific goals
around performance and API?

If Go's stdlib were so comprehensive such that frameworks were not necessary,
I would get your point, but it's my understanding Go exists as a simple
language on which to build larger programs, not as a "one true way" language
with everything included.

~~~
stirner
> it's my understanding Go exists as a simple language on which to build
> larger programs, not as a "one true way" language with everything included.

I agree. However, there is a big difference between libraries and frameworks.
I believe frameworks are an antipattern in any language, not just Go, but Go's
emphasis on simplicity makes frameworks for it especially grating to me.

Rather than poorly summarize, I'll link two of my favorite articles
criticizing frameworks; one is humorous [1] and the other is more serious [2].

[1]
[http://discuss.joelonsoftware.com/?joel.3.219431.12](http://discuss.joelonsoftware.com/?joel.3.219431.12)

[2] [http://tomasp.net/blog/2015/library-
frameworks/](http://tomasp.net/blog/2015/library-frameworks/)

~~~
codezero
Thanks for the links. I misunderstood your displeasure with frameworks as an
issue with Go, it makes more sense that you (and many others) see frameworks
as bad. The arguments against them are pretty compelling, but I can't fault
someone for building one :P

