goodwink

This article would have been much better without the first section on technology trends. I almost stopped reading when it looked like analyst generated pr (perhaps demonstrating the AI trend with auto generated content).

I think he might mean things more like CES and other trade shows. Apple has frequently been involved in technical conferences.

I'd like to see that used on a plane in economy. Given that I travel a lot and don't always end up in business/first, this is one of the first questions I ask myself when considering any new laptop.

This is a good thing, not a bad thing. A market of one is a lonely place to be. It's much better to have a large company creating the market and bearing the expense and then leaving niches open for you to fill.

Do you have ability to import data from a previous provider to allow reporting history to stay intact?

The original code is like this because it's an exercise. Of course ruby has hashes.

Any chance this will be open sourced later so that we can run the docker stuff locally for our own team's usage for training etc.?

Oh, the whole page is a flash video and I have no idea what this might be or why it would be worth my time to allow flash block to play it?

...Back

This really should have been written in the form of a parody of Snakes on a Plane.

I see it on ecommerce sites all the time. It's on NewEgg for example last I checked. It's very common.

This seems really cool, I'd love to see it integrated with GitHub so that when I push my code to my repos it notifies CommitQ of the diffs and it can process them. I don't need a new host for my code, but more insight into what's going on there? Yes, please, I'll certainly pay for that!

That's a very good point; I hadn't thought of it that way. Maybe this is some small part of why we seem to keep flocking to the new kids on the block.

There are performance numbers for a framework (Cake PHP, for example) and for the raw primitives of the platform it runs on (PHP, in that case). By finding the ratio between the two one can arrive at the performance loss attributable primarily to the framework you've chosen.

See my "framework optimization index" in comments below for a rundown on all these ratios which I was able to back out from this set of benchmarks.

Could you point me at an example of an idiomatic, non-trivial Go REST/JSON API server? I've been trying for a while to find something to read to get a better handle on good patterns and idiomatic Go, but I haven't really come up with anything. I've found some very good examples of much lower-level type stuff, but I think I have a decent handle on that type of Go already. What I really would like is a good example of how people are using the higher level parts of the standard library, particularly net/http etc.

If you have developers who for one reason or another prefer a given platform, then the most important performance comparisons are about how close various frameworks on that platform get to the performance of the platform itself.

Knowing how much I'm giving up in performance in order to get the features a given framework gives me is an important consideration. Also understanding when it's worthwhile to work outside the framework on the bare platform given the speedup I'll get versus the cost I'll incur by doing so is a very important optimization decision-making tool.

I believe they're encouraging pull requests to fix that sort of thing. It will be interesting to see if it helps to that degree; I hope so!

Passenger wouldn't be my choice personally, but I don't think there's anything non "idiomatic" about it. Engine Yard, Cloud 66, etc. use passenger in their PaaS configs, it's been very popular (on the wane now, but still), etc. It seems fair enough and the differences aren't going to be the sort of order of magnitude change which would really matter on this sort of thing regardless.

Thanks, this comment really helped me in my evaluation of Go today. I had been playing around with 1.0.3 for a couple days, but tip is definitely where it's at.

Could you elaborate? Their website seems to indicate that they are a very polyglot shop, not someone pushing a JVM agenda:

"On the back-end, we use Java, Ruby, Python, .NET, PHP and others based on what makes sense balancing server performance, scalability, hosting costs, development efficiency, and your internal development team's capabilities."

Wow, directly on tip? That seems to speak very highly of the day-to-day development stability of Go.

These could probably be further broken down into micro-frameworks (like Express, Sinatra, Vert.x etc.) and large MVC frameworks (like Play and Rails).

Gemini is sort of an outlier that doesn't really fit either category well, but the micro-frameworks have a fairly consistently higher framework optimization index than the large MVC frameworks which is as expected.

Express and Sinatra really stand out as widely-used, very high percentage of platform performance retained frameworks here. I've never used Vert.x, but I will certainly look into it after seeing this. I'm very impressed that Express is so high on this list when it is relatively young compared to some of the others and the Node platform is also relatively young.

Play seems particularly disappointing here since it seems any good performance there is almost entirely attributable to the fast JVM it's running on. Compojure is also a bit disappointing here (I use it quite a bit).

Here's a quick version of the framework optimization index. Higher is better (ratio of framework performance to raw platform performance, multiplied by 100 for scale):

Framework Framework Index

Gemini 87.88

Vert.x 76.29

Express 68.85

Sinatra-Ruby 67.88

WebGo 51.08

Compojure 45.69

Rails-Ruby 31.75

Wicket 29.33

Rails-Jruby 20.09

Play 18.02

Sinatra-Jruby 15.96

Tapestry 13.57

Spring 13.48

Grails 7.11

Cake 1.17

Were these the new 2nd-generation large instances or the original ones?

I think Go is almost the ideal example here, you're right. Go provides a pretty rich "standard library" for writing web serving stuff so it's a good place where you could really imagine writing your performance critical stuff just on the base platform even if you use something like Webgo for the rest of your app.

Some of the other platforms are much less amenable to that since the standard primitives the platform exposes are very primitive indeed (servlets api, rack api, etc.). Perhaps there's some value in looking at how your favorite framework stacks up against its raw platform and trying to contribute some optimizations to close the gap a bit.

One of the most interesting things this comparison brings out to me is not so much the differences between the various frameworks (although the differences between options on the same platform is definitely very useful information), but also the issue that few of us seem to think about these days: the cost of any of the frameworks above the bare standard library of the platform its hosted on.

Theres a consistant, considerable gap between their "raw" benchmarks (things like netty, node, plain php, etc.) and frameworks hosted on those same platforms. I think this is something we should keep in mind when we're tuning performance-sensitive portions of APIs and the like. We may actually need to revisit our framework choice and implement selected portions outside of it (just like ruby developers sometimes write performance-critical pieces of gems in C etc.) or optimize the framework further.

I'd like to crunch these numbers further to get a "framework optimization index" which would be the percentage slowdown or ratio of performance between the host platform and the performance of the framework on top of it. I might do this later if I get a chance.

After having a look at the code on github it looks like they did set up multi processes/threads to really test the scalability on these platforms. That's really impressive, way beyond the single thread experiment I would have anticipated something like this doing! Wow!

What was the parallelization like across these tests? Were they all running single thread/process mode or did you try to take advantage of threading/multiple-processes/etc. to optimize a production-like performance across all the different frameworks? If the latter, that's a really impressive amount of work!

I'd be interested to see performance for Vert.x on its other hosts (this is the JVM version, I believe).

Could you elaborate on the other heroku in a box offerings building on docker? Sounds pretty interesting!

Sorry for the surprise HN post! ;)

I'm wondering if there's any docs for deployment beyond the python example I saw. I'd like to deploy nodejs and go apps in particular.

Thanks for the interesting project!