Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Frameworks Round 6

techempower.com

Post reply on HN
Print view View original

31–40 of 135 posts

Re: Frameworks Round 6

#31

Post by candybar »

RyanZAG wrote: post #25
bliker wrote: post #24

Honest question: Why are most of the frameworks that I know of in bottom half? When does speed becomes relevant?

Three reasons as to the hierarchy: 1) Most popular frameworks you would encounter run on higher level dynamic languages such as PHP, Ruby or Python. These languages are a decent bit slower than performance optimized languages. The languages towards the top are all C, Java, Go, etc. 2) The frameworks towards the top are generally lower level - they do less automatic 'magic' than the more popular frameworks that handle…

I would go even further - performance is relevant even if your margin is high, because high baseline performance means you can trade off performance for speed of development and/or business considerations elsewhere. Scaling also doesn't come for free and it's harder, not merely more costly, to manage more servers.

Re: Frameworks Round 6

#32

Post by bliker »

YcombRegBroken wrote: post #26
VeejayRampay wrote: post #20

For such a young language, I'm really surprised by the performance of Go there. Quite awesome.

Round 4 of these tests is what triggered my dive into Go this past month, and it has been a revelation. If you add in the concurrency capabilities, the language simplicity, and nice balance between overly terse syntax (Python one liners...) and overly verbose typed languages (Java), the whole package is even more impressive. The only real thing I think it is missing is a "high productivity" application framework like…

how about http://robfig.github.io/revel/ ? I just skimmed thru their manual and it seems quite promising

Re: Frameworks Round 6

#33

Post by iaskwhy »

spamizbad wrote: post #18
iaskwhy wrote: post #6

Earlier quoted context omitted.

I guess you need to change the Hardware to "Win" to see it shining.

Even then it tends to run behind Go and Node.js in most tests. Once Round 7 includes MSSQL we'll see a more accurate picture.

I don't find it a problem seeing it running behind Go and Node.js, I believe C# is another beast so it's a trade-off.

Re: Frameworks Round 6

#34

Post by Peaker »

YcombRegBroken wrote: post #26
VeejayRampay wrote: post #20

For such a young language, I'm really surprised by the performance of Go there. Quite awesome.

Round 4 of these tests is what triggered my dive into Go this past month, and it has been a revelation. If you add in the concurrency capabilities, the language simplicity, and nice balance between overly terse syntax (Python one liners...) and overly verbose typed languages (Java), the whole package is even more impressive. The only real thing I think it is missing is a "high productivity" application framework like…

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

Re: Frameworks Round 6

#35

Post by camus »

RyanZAG wrote: post #25
bliker wrote: post #24

Honest question: Why are most of the frameworks that I know of in bottom half? When does speed becomes relevant?

Three reasons as to the hierarchy: 1) Most popular frameworks you would encounter run on higher level dynamic languages such as PHP, Ruby or Python. These languages are a decent bit slower than performance optimized languages. The languages towards the top are all C, Java, Go, etc. 2) The frameworks towards the top are generally lower level - they do less automatic 'magic' than the more popular frameworks that handle…

> 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 do less automatic 'magic' than the more popular frameworks that handle things like validation automatically.

Not really Spring,Struts,etc ... are not really low level.

There is a paradigm shift today. There is more and more demand for realtime apps. And these cannot take advantage of http proxying or caching. So the solutions that perform badely at concurency will not be seen as relevant in the future.

Re: Frameworks Round 6

#36

Post by camus »

candybar wrote: post #31
RyanZAG wrote: post #25

Earlier quoted context omitted.

Three reasons as to the hierarchy: 1) Most popular frameworks you would encounter run on higher level dynamic languages such as PHP, Ruby or Python. These languages are a decent bit slower than performance optimized languages. The languages towards the top are all C, Java, Go, etc. 2) The frameworks towards the top are generally lower level - they do less automatic 'magic' than the more popular frameworks that handle…

I would go even further - performance is relevant even if your margin is high, because high baseline performance means you can trade off performance for speed of development and/or business considerations elsewhere. Scaling also doesn't come for free and it's harder, not merely more costly, to manage more servers.

> Scaling also doesn't come for free and it's harder,

that's a very good point.Scaling definetly doesnt come for free, especially when scaling databases.

Re: Frameworks Round 6

#37

Post by bliker »

RyanZAG wrote: post #25
bliker wrote: post #24

Honest question: Why are most of the frameworks that I know of in bottom half? When does speed becomes relevant?

Three reasons as to the hierarchy: 1) Most popular frameworks you would encounter run on higher level dynamic languages such as PHP, Ruby or Python. These languages are a decent bit slower than performance optimized languages. The languages towards the top are all C, Java, Go, etc. 2) The frameworks towards the top are generally lower level - they do less automatic 'magic' than the more popular frameworks that handle…

Thank you for great response.

But for me all this seems quite biased towards small Frameworks/Platforms. I will hardly ever serve one JSON response form full stack framework. If I just made some C server that would do those tasks very well it would be first in this list but very far of anything of value.

Albert Einstein once wrote, “Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.”

Re: Frameworks Round 6

#38

Post by drummingds »

bhauer wrote: post #16
clhodapp wrote: post #11

The play-slick results seem to be missing. Was there some sort of problem?

I had not named it uniquely. I've changed its name to "play-slick." Thanks for pointing that out!

Thanks for updating that. I noticed that the Slick version seems to outperform the regular Anorm version in most tests. Do you have any insight into why that might be? I figured it would've been the other way around.

Re: Frameworks Round 6

#39

Post by rallison »

bliker wrote: post #37
RyanZAG wrote: post #25

Earlier quoted context omitted.

Three reasons as to the hierarchy: 1) Most popular frameworks you would encounter run on higher level dynamic languages such as PHP, Ruby or Python. These languages are a decent bit slower than performance optimized languages. The languages towards the top are all C, Java, Go, etc. 2) The frameworks towards the top are generally lower level - they do less automatic 'magic' than the more popular frameworks that handle…

Thank you for great response. But for me all this seems quite biased towards small Frameworks/Platforms. I will hardly ever serve one JSON response form full stack framework. If I just made some C server that would do those tasks very well it would be first in this list but very far of anything of value. Albert Einstein once wrote, “Everybody is a genius. But if you judge a fish by its ability to climb a tree, it wil…

There is no evidence that Einstein ever wrote or said that [1].

[1] http://quoteinvestigator.com/2013/04/06/fish-climb/

Re: Frameworks Round 6

#40

Post by dom96 »

bhauer wrote: post #30
dom96 wrote: post #29

Finally! I was disappointed when this round was postponed. I couldn't wait to see how well my framework (Jester; https://github.com/dom96/jester ) performed, not only because it was my framework but also because it is written in Nimrod. I am a bit disappointed by the results but at least there is a lot of room to improve now, I didn't have much time to properly implement concurrency for Jester so I opted for just spa…

Finally indeed! In future rounds, I hope that we can spend less time trying to resolve problems--if there are problems, we'll just post the results and move on to the next round. Better to keep iterating, and allow the experts who work with each framework resolve issues as they come up. Thanks very much for contributing Jester to the test! I really appreciate your spirit and hope to see it improve in Round 7 as well.…

Indeed, although people may be disappointed if their framework fails and they have to wait another month for another round of results, but then I suppose the next round will come a lot quicker if you have less issues to fix.

No problem at all. Thank you for merging my process spawning silliness. You will definitely see a lot more improvements from me :)

EDIT: A little issue I just noticed: the jester "Front-end server" is shown as "None" when in fact it's "nginx".

Post reply on HN