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

111–120 of 125 posts

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

#111

Post by kasey_junk »

benbjohnson wrote: post #71
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've been using a local key/value store as my backing database and it works great. Primary key access is usually less than 1µs and net/http is typically my bottleneck. That being said, unless you're getting a massive number of requests, using a specialized HTTP library seems like overkill.

What do you mean by usually? What do the "bad" cases look like and how often do they happen? How are you measuring that key access and is it happening across cores? Are you setting any OS level settings around isolation?

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

#112

Post by kasey_junk »

weberc2 wrote: post #91
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?

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

Nitpick c# has value types

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

#113

Post by Shorel »

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…

> C has no package management solution at all.

Curiously, I just found this today:

https://conan.io/

It seems to be a full featured package manager to use with C and C++.

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

#114

Post by mtanski »

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…

redis by default does not fsync every change, instead it syncs every second. So no it's data reliability is not on par with Postgres in the default configuration.

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

#115

Post by ngrilly »

kasey_junk wrote: post #112
weberc2 wrote: post #91

Earlier quoted context omitted.

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

Nitpick c# has value types

In C#, can you create an array of (x, y, z) tuples, where x, y and z are floats, and the whole array is store contiguously, without any indirection? Last time I checked C# documentation, it wasn't possible, but maybe I missed something.

Edit:

Ok, I definitely missed something ;-) I checked again C# documentation and kasey_junk is right. The tuple can be implemented as a struct, which is a value type (not a reference type), and arrays items are stored in contiguous memory. This is a big advantage of C# over Java (value types are planned for a future version of Java).

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

#116

Post by ngrilly »

pcwalton wrote: post #97
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…

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

You forgot to mention a significant another drawback of most JIT implementations, compared to AOT: the bigger memory footprint.

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

#117

Post by ngrilly »

pcwalton wrote: post #97
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…

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

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

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

#118

Post by eddyb »

ngrilly wrote: post #117
pcwalton wrote: post #97

Earlier quoted context omitted.

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

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

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.

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

#119

Post by weberc2 »

kasey_junk wrote: post #112
weberc2 wrote: post #91

Earlier quoted context omitted.

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

Nitpick c# has value types

I know. Java and C# have primitives as well, which are also values and not references. I was speaking broadly. :)

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

#120

Post by ngrilly »

eddyb wrote: post #118
ngrilly wrote: post #117

Earlier quoted context omitted.

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

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.

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?
Post reply on HN