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.
Frameworks Round 6
81–90 of 135 posts
Re: Frameworks Round 6
#82Re: Frameworks Round 6
#83I 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?
We'd rather test Rails 4 than obsolete versions of Rails: https://github.com/TechEmpower/FrameworkBenchmarks/issues/35...
Re: Frameworks Round 6
#84Thanks 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…
Re: Frameworks Round 6
#85Earlier 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.
Re: Frameworks Round 6
#86Earlier 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?
google trends to these languages http://www.google.com/trends/explore?q=clojure%2C%20%20angul...
Re: Frameworks Round 6
#87What kind of optimizations are done ?
Re: Frameworks Round 6
#88How 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…
Re: Frameworks Round 6
#89Earlier 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…
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
#90Earlier 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…
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.