Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Iris: Fast back-end web framework for Go

iris-go.com

Post reply on HN
Print view View original

61–70 of 125 posts

Re: Iris: Fast back-end web framework for Go

#61

Post by qaq »

Svenskunganka wrote: post #24
Bombthecat wrote: post #18

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…

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

Re: Iris: Fast back-end web framework for Go

#62

Post by gummiruessel »

mappu wrote: post #3

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.

It's worth noting that fasthttp doesn't support HTTP/2.0.

According to the README, there are plans for it in the future.

Re: Iris: Fast back-end web framework for Go

#63

Post by znpy »

shadowmint wrote: post #46
oneloop wrote: post #23

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?

C is hard. You're right though, why not use C? It's a good language, and it's hard to beat for it's low level powers, portability and speed. What go gives you is high level productivity, testing, a solution for package management (abit a rubbish one), and a good ecosystem of 3rd party libraries for things like AWS. The things that suck about C: - It's hard to do right. There's a great book called 'Deep C Secrets' on…

Besides, keep in mind that the C language has some "weird corners" and in some considtions, you might encounter an "unspecified behaviour" scenario.

For short, there are some cases in which the C language specification does not tell you what to do and how to interprete code and in this cases, the choice is left to the compiler.

This is not trivial as it might look.

For example, what happens when you omit the return statement at the end of a function? GCC will to automatically insert a return statement for you, but Clang will not. Both are perfectly fine behaviours... As long as you are aware of it.

If you always compiled your code with GCC and suddenly switch to clang you might see weird shit, because the processor reached the end of your function, found no return instruction, and just went ahead and executed whatever code was put after your function (and it might not be so obvious what code is there).

(But in a way, this is part of the beauty of the C language: there is very little abstraction, and it is easy to understand what will happen when you run C code.)

Re: Iris: Fast back-end web framework for Go

#64

Post by nibs »

znpy wrote: post #48
rattray wrote: post #5

Features: 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...

Given the state of the art of golang ORMs, I guess this might be a plus. I have tried xorm and gorm (besides database/sql) and while I settled on gorm, they both have some fundamental design flaws: * xorm onInsert/onUpdate hooks are designed the wrong way. Last time I tried, hooks received object instances by value and not by reference, meaning I could not actually update things before hitting the database. * both xo…

I have had good results with Beego/Beego ORM lately.

Re: Iris: Fast back-end web framework for Go

#65

Post by TheHydroImpulse »

cakoose wrote: post #44
andkenneth wrote: post #35

Earlier quoted context omitted.

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…

There are two things here -- how fast can a language be in theory vs how fast a particular implementation is. Interpreters are typically slower (though simple to write and portable). The standard Python/Ruby/PHP implementations are interpreters. (The Python interpreter doesn't interpret from source every time, though; it usually uses the bytecode from previous runs.) Implementations that generate machine code are mor…

The early version of hiphop (Facebooks php compiler) would compile PHP into C++. It was really interesting how they went from C++ to now a full featured JIT.

Re: Iris: Fast back-end web framework for Go

#66

Post by TheHydroImpulse »

oneloop wrote: post #53
insertnickname wrote: post #26

Earlier quoted context omitted.

Go actually lets you work at a quite high level, much like C# or Java (and the performance is in the same ballpark). I think a better question to ask is: why is Python so slow?

Ok, so why is Python so slow (comparatively)? I had understood that must of the speed-critical tasks in python were done by wrappers of lower-level C code. Example: numpy. Is this not correct?

The reason it's slow is because python interprets it's input. It essentially introduces major indirection for instructions to be executed.

So for '1 + 1', you can't just output some fast x86 instruction and inline it. You'll usually need to jump to where the python vm will do 'a + b' in C. You're having to do a bunch of redundant work at a higher level to emulate the CPU (sorta).

That's why you have JIT compilers that will read '1 + 1' and compile the appropriate machine code, store that in an executable memory region and jump to it. First time might be slow, but after that it's pretty fast. Because you need to jump to the dynamically generated code, you usually compile whole functions at a time.

This topic is super complicated but also super interested but I tried to simplify it a bit here.

Re: Iris: Fast back-end web framework for Go

#67

Post by piotrkubisa »

ptman wrote: post #40
piotrkubisa wrote: post #13

Earlier quoted context omitted.

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 u…

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

Indeed. Thank you for pointing this out.

Re: Iris: Fast back-end web framework for Go

#68

Post by marcus_holmes »

spriggan3 wrote: post #30
stirner wrote: post #9

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.

> 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 mid…

I enjoyed coding in Go, but the "community" killed all enjoyment of the language for me.

I took off my big boy trousers, put on my human being shorts, and decided to take my enthusiasm elsewhere.

Shame, because the language does have a lot going for it.

Re: Iris: Fast back-end web framework for Go

#69

Post by insertnickname »

oneloop wrote: post #53
insertnickname wrote: post #26

Earlier quoted context omitted.

Go actually lets you work at a quite high level, much like C# or Java (and the performance is in the same ballpark). I think a better question to ask is: why is Python so slow?

Ok, so why is Python so slow (comparatively)? I had understood that must of the speed-critical tasks in python were done by wrappers of lower-level C code. Example: numpy. Is this not correct?

You can indeed do that, and there are other ways to speed up Python (PyPy, Cython, or even just writing more efficient Python code). However, the problem is that you now have to write C.

A lot of the slowness in Python probably comes from the many memory allocations all over the place. Go gives you a lot of control over allocations even though it is a garbage collected language.

These slides posted by another commenter has some good points about why Python is so slow: https://speakerdeck.com/alex/why-python-ruby-and-javascript-...

Interestingly, there was actually a talk at PyCon US 2016 about using Go's http server in Python via C. https://www.youtube.com/watch?v=CkDwb5koRTc

Re: Iris: Fast back-end web framework for Go

#70

Post by calcifer »

qaq wrote: post #61
Svenskunganka wrote: post #24

Earlier quoted context omitted.

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…

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

Redis has transactions as well.
Post reply on HN