Live data from Hacker News

Iris: Fast back-end web framework for Go

iris-go.com

91–100 of 125 posts

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

#91
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?

Former C++ dev, current Python dev here.

Go is somewhere between Python and C. Go has a garbage collector, scheduler, and runtime type information (aka reflection, aka introspection). Like C, Go has "value types" whereas everything in Python (or even Java/C#) is a reference (this gives more control over memory layout, generaly less indirection, and generally less work for the garbage collector). In this sense, Go performs similarly to Java for serial tasks.

For parallel and concurrent tasks (e.g., web servers), things get more interesting. Efficient concurrency in C is hard, and efficient parallelism in Python is hard (async IO makes efficient concurrency easier, but it's not widely used as far as I can tell). Go's goroutines solve both of these problems by providing a lightweight threading mechanism that abstracts over both OS threads and async IO (I/O is always async in Go, but there are no callbacks, promises, or async/await). These lightweight threads (goroutines) can be dispatched and moved across thread boundaries, and there is no Global Interpreter Lock (unlike Python) so shared memory parallelism is easy.

Basically, Go is as easy as Python (even easier for nontrivial applications in my opinion), about 20-30 times faster than Python (or about half as fast as C or on par with Java/C#), and much much nicer for concurrent and parallel tasks than all of the above.

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

#92
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.

The project creator is from Greece and is not a native English speaker. How about maybe cut some slack.

Sure, so long as he's open to incorporating corrections.

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

#93
post #16

Earlier quoted context omitted.

English is a language with grammar that has a Stack Exchange site and can be Googled. The typos on the page are common for native English speakers who don't take the time or effort to check their writing for correctness. The author did not grow up from babyhood writing Go programs, but we expect them to be correct and adhere to known idioms.

The same can, for example, be said about Russian, but I doubt you would expect anyone with minimal experience in Russian to write without any errors despite that fact.

Being a learner is laudable. However, that means being open to constructive criticism.

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

#94
post #44

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 ability to monkey-patch code

"The liability to monkey-patch" in my opinion. :p

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

#95
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.

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 world is not only about CRUD apps with a database backend.

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

#96
post #88

Earlier quoted context omitted.

But it also doesn't perform as well with large data sets and has less compiler optimizations and no JIT. Saying Go is much faster than Java is nonsense.

The speed at which a big data set is processed has nothing to do with the language or its' compiler. It's the way in which the data set is streamed through memory by a particular program. Go offers two standardized interfaces for this, `io.Reader` and `io.Writer`. Also, if the data set can be batched, it's trivial to parallelize processing in Go, while it's a big hurdle in Java. A JIT is not a performance feature per…

The big data set stuff I generalized around has more to do with the runtimes involved. Most JVM gc systems for instance are moving collectors while the golang one isn't (or wasn't last I looked). This can cause slow downs in comparison to a comparable GC environment especially around large data sets in long running environments.

"And Go allows for more control about the memory layout of structs/classes and arrays." Is an absolutely true statement, and it means that for some classes of problems (namely systems that prioritize GC latency for throughput) golang might be faster. The opposite is also true, especially with regard to large interdependent data sets, the golang runtime handles those worse than most JVMs.

I'd also completely disagree with your statement "Also, if the data set can be batched, it's trivial to parallelize processing in Go, while it's a big hurdle in Java." Especially with regard to "fast". There are more & better high performance concurrency libraries in Java than there are in go.

All that said, I was really reacting to this line "This is much faster than C# or Java, which compile to an intermediate interface" which is utter nonsense.

In the end, talking about performance in such large grained ways is usually not valuable but I'm willing to say that golang performs in the same category of performance as most jvms and that calling go faster than java is nonsense unless you speak about very specific cases.

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

#97
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?

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…

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

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

#98
post #42

Earlier quoted context omitted.

The GIL makes Python faster than a Python without it would be.

yeah, the GIL only slows down threaded code. The big reason that the GIL hasn't been removed is that any patch removing the GIL slows single threaded performance.

The GIL massively slows down threaded code. To the point where (almost?) all multithreaded cases are actually slower than single threaded cases. :(

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

#99
post #84

Earlier quoted context omitted.

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

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

You're missing the distinction between frameworks and libraries. Libraries are the preferred way to reuse code in Go. Generally, libraries have a "do one thing well" approach and can be easily swapped out; frameworks try to do everything, and they tend to try to integrate more deeply into your application (which makes them harder to swap out).

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

#100
post #79

Earlier quoted context omitted.

It's worth noting that fasthttp doesn't support HTTP/2.0. According to the README, there are plans for it in the future.

Hmm, thus not so fast after all ...

Who's deploying a go web server without putting it behind nginx? Not many people.
Post reply on HN