Live data from Hacker News

Frameworks Round 6

techempower.com

81–90 of 135 posts

Re: Frameworks Round 6

#81

I would love to see how the Goliath async server (Ruby version of Node.js is one way of looking at it - http://goliath.io ) performs, as I've recently started looking into it for a part of a project.

I was just about to post this. And will the next round be tested on Rails 4.0?

Re: Frameworks Round 6

#82
i don't see any mention of uwsgi or gevent in these benchmarks. Deploying Python apps without properly configuring the container/webserver will skew the results considerably (probably applicable to a couple of other entries as well).

Re: Frameworks Round 6

#83
post #81

I would love to see how the Goliath async server (Ruby version of Node.js is one way of looking at it - http://goliath.io ) performs, as I've recently started looking into it for a part of a project.

I was just about to post this. And will the next round be tested on Rails 4.0?

The best way to ensure Goliath is tested is to submit a pull request.

We'd rather test Rails 4 than obsolete versions of Rails: https://github.com/TechEmpower/FrameworkBenchmarks/issues/35...

Re: Frameworks Round 6

#84
post #2

Thanks for posting this, amarsahinovic. This is the latest round of our ongoing project to benchmark the performance of fundamental services provided by modern web application frameworks. With the continued contributions of the developer community, the number of frameworks and platforms included is now 74! Round 6 also adds the often-requested plaintext test with HTTP pipelining (thanks in large part to William Gloze…

are you going to include gevent (I.e. bottle/flask + gunicorn with gevent workers, and uwsgi + gevent workers) ?

Re: Frameworks Round 6

#85
post #66
post #60

Earlier quoted context omitted.

Thank you, now I understand why I couldn't find anything useful on this page http://www.eclipse.org/gemini/web/ :) Nevertheless I am still looking for good resources on getting started with Java (ecosystem wise, not the language itself).

Have you considered starting with Grails? It's a much easier jump into the "java-ish" world. The main benefit is you can choose to run a grails application and rely on java jars for when you need performance boosts.

We've been using Groovy internally for a few years for prototyping and experimentation. I thought about slowly introducing Grails as an alternative to Spring for some projects. My experience was that it vaguely reminded me of Rails but needed a lot more polish. I had a huge issue trying to chase down archaic stacktraces and found that there is little developer momentum pushing it forward. I usually found myself googling and reading random blogs to figure out simple things I couldn't infer from the docs. Where as Rails magically makes things work, I found that a lot of times Grails made things magically not work. I wouldn't personally suggest it for anything customer facing.

Re: Frameworks Round 6

#86
post #35

Earlier quoted context omitted.

> Basically, the relevance of speed is directly related to your margin. True though the average PHP developper is usually cheaper than the Go or Java one. Paying people is usually more expensive than buying server instances on Amazon. High end PHP dev is as hard as Java .. The problem is that the high end PHP frameworks are at the bottom of the list... > The frameworks towards the top are generally lower level - they…

What do you suggest one should keep an eye on to stay relevant in the future?

imo lua (openresty for nginx in benchmarks, Lapis framework looks tight) and go. in reality go, clojure, nodejs and angular will probably be the most relevant

google trends to these languages http://www.google.com/trends/explore?q=clojure%2C%20%20angul...

Re: Frameworks Round 6

#87
Can anyone explain why the "gemini" framework with an ORM outperforms raw servlets/queries in almost all the cases?

What kind of optimizations are done ?

Re: Frameworks Round 6

#88

How are certain languages so much faster even when pulling from the database? Surely the database would be the bottleneck here? Surely if it's something cool the driver is doing, that could be implemented in other drivers? Also, why are some frameworks on there a bunch of times (e.g. ASP MVC)?

> Surely the database would be the bottleneck here? The idea that "it doesn't matter which language you use because DB would be your bottleneck" might have been true 10 years ago but it's definitely not true anymore. Latest versions of MySQL and Postgresql are extremely fast. They are written in C/C++ and heavily optimized. MySQL serving data from RAM can easily do 500K+ rps on a commodity server. Even if you need to…

Ok, but say we use vanilla Python WSGI with a psycopg2 (C Python PostgreSQL extension) directly. Will this come close to the performance of the C++ framework thing?

Re: Frameworks Round 6

#89
post #78
post #34

Earlier quoted context omitted.

Have you tried modern ML-style languages? e.g: Haskell, OCaml, F#? They also combine the nice conciseness of Python, with great concurrency (better than Go) and a lot more safety (less late night crashes).

Since you are replying to this in the Haskell thread - Go clearly performs FAR better than Haskell on these simple benchmarks. So as far as I can tell, the pros of using Haskell over Go would be 1) More safety from crashes while the Cons of Haskell would be 1) Slightly slower than Go at HTTP 2) Far, far slower than Go at database queries 3) Much steeper learning curve 4) Based on the history of ML languages, will nev…

1. More safety from bugs in general, not just crashes. Haskell programs will generally be more reliable than Go programs.

2. If you look at the Benchmarks game, you will actually see that Haskell beats go there.

I think this benchmark is far narrower than the Benchmarks game and is thus less representative.

3. shouldn't really be a serious consideration for a career programmer (weeks to a couple months of learning to be more effective for years to come is a no-brainer).

4. is untrue, Haskell has already gained more popularity than the ML languages had in the past. And so is F#.

Re: Frameworks Round 6

#90
post #76
post #58

Earlier quoted context omitted.

What do you mean by "mental cost" here? Cost of initial learning? Then I agree... But learning a language is an O(1) cost that takes a few weeks to a few months. We program with the language for many years. I never said the Go runtime will crash, but your programs will, because of unsafe nullability, mutability in the concurrently shared state, and various other problems in Go. Better concurrency in Haskell: In addit…

> I never said the Go runtime will crash, but your programs will, because of unsafe nullability, mutability in the concurrently shared state, and various other problems in Go. Personally, these problems are not what are a time-sink for me. The problems that I spend a vast majority of my time on tend to fall into two categories. First, there are design problems. i.e. how do you model your data to be queryable, how do…

I think people tend to underestimate the amount of time they spend on problems, when those are uninteresting. A single null dereference error may be trivial to fix, but the overhead around fixing any bug may be costly. For example, you might need to deploy a whole new version, rerun test suites and have a bunch of meetings. Then after all of this, you might remember that the problem only costed you 10 minutes of fixing the bug.

When you implement a red-black-tree, do you not spend any time testing your invariants? Or figuring out the bugs? That's a good example of where the Haskell type system can simply give you compile time guarantees saving you from bugs and from having to test them.

I also worry about the problems you mention, many of which Haskell indeed doesn't help much with. I don't see how these problems (which you solve once, usually by reusing a library) are what costs the majority of the time. A big, non-trivial implementation has bugs and will require testing. Haskell will have less bugs, and require less tests. This is a pretty big deal.

It's weird that you bring Twitter as an example, as they canned a dynamic language solution for a static language that is in many ways very similar to Haskell.

I've seen multiple large scale projects in dynamic languages. They all fail to scale well, both performance-wise and maintenance-wise. Statically-typed systems scale far better along both of these axis.

Post reply on HN