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

121–125 of 125 posts

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

#121

Post by cakoose »

TheHydroImpulse wrote: post #65
cakoose wrote: post #44

Earlier quoted context omitted.

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.

Right. But just to be clear, C++ was an implementation detail. You could treat the entire toolchain as a black box that read in PHP code and produced a single executable binary.

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

#122

Post by kibwen »

ngrilly wrote: post #120
eddyb wrote: post #118

Earlier quoted context omitted.

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?

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.

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

#123

Post by ngrilly »

kibwen wrote: post #122
ngrilly wrote: post #120

Earlier quoted context omitted.

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?

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

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

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

#124

Post by fweespeech »

Svenskunganka wrote: post #105
fweespeech wrote: post #74

Earlier quoted context omitted.

https://muut.com/blog/news/april-2014-service-failure.html https://muut.com/blog/technology/redis-as-primary-datastore-... Counter point of a real world implementation where they tried to make it the primary data store.

Have you even read the article? This was caused by Mongo running with a wrong flag, and the authors explicitly said that their backup script only contained ONE backup. That's bad engineering, not fault with Redis. Redis is extremely safe if you configure it correctly.

Yes, on a small number of nodes it works in a handful of use cases. That isn't the same as it being equal and equivalent in terms of reliability at scale.

They resorted to weird hack-y shit for something I use MySQL or Postgres for on a regular basis. So have most people who built stuff on Redis like this:

> I use Redis as the primary and only database. > Additionally, it has data persistence reliability on par with Postgres and other battle-tested databases[0], so couldn't be happier about that.

Post reply on HN