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

101–110 of 135 posts

Re: Frameworks Round 6

#101

Post by Peaker »

TylerE wrote: post #94
Peaker wrote: post #90

Earlier quoted context omitted.

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

I can't remember the last time I implemented a data-structure in a web framework. You just use the built in dictionary/hash table and get on with life.

Well, whenever you write non-trivial code, your code is going to have invariants. These invariants can be partially tested or they can be fully type-checked. The latter is better and cheaper, when available. Haskell makes the latter available far more often, so you don't have to pay for the former. This is not just useful for data structures, but code in general.

Re: Frameworks Round 6

#102

Post by bhauer »

ditados wrote: post #84
bhauer wrote: 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) ?

We would certainly like to include that configuration. If you have time and are willing to contribute, we'd love to receive that as a pull request.

Re: Frameworks Round 6

#103

Post by YcombRegBroken »

Peaker wrote: post #90
agentS wrote: post #76

Earlier quoted context omitted.

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

I'm a little confused here. You realize that Go is also statically typed, right? I'm not sure where any debate about dynamic languages started. The points you make about static vs dynamic are valid, just not relavent at the moment.

It's funny, too, how you talk about "implementing a red black tree" like it's an everyday occurrence. I'm guessing you are a teacher/researcher (in which case this entire discussion makes much more sense). On any application team I've worked with (in the valley or out), implementing a binary tree from scratch would require extreme justification and literally have to be the only way possible to solve the problem.

Re: Frameworks Round 6

#104

Post by TylerE »

Peaker wrote: post #101
TylerE wrote: post #94

Earlier quoted context omitted.

I can't remember the last time I implemented a data-structure in a web framework. You just use the built in dictionary/hash table and get on with life.

Well, whenever you write non-trivial code, your code is going to have invariants. These invariants can be partially tested or they can be fully type-checked. The latter is better and cheaper, when available. Haskell makes the latter available far more often, so you don't have to pay for the former. This is not just useful for data structures, but code in general.

This post kind of sums it up for me. No, I'm not thinking about invariants. We're talking about writing a web app here. Typing is pretty meaningless when 99.9% of your data is just strings.

Re: Frameworks Round 6

#105

Post by bhauer »

joeblau wrote: post #65
continuations wrote: post #43

cpoll-cppsp made huge performance gains from round 5 to 6. For example multiple queries went from 1,872 rps in round 5 to 7,252 in round 6. What caused that? Also what happened to cpoll-cppsp in the plaintext test? Its performance there took a deep dive.

Is there any reason why it is so slow on plain text?

Looks like there was a problem in cpoll-cppsp: https://github.com/TechEmpower/FrameworkBenchmarks/pull/364

This will be merged in for Round 7.

Re: Frameworks Round 6

#106

Post by Peaker »

TylerE wrote: post #104
Peaker wrote: post #101

Earlier quoted context omitted.

Well, whenever you write non-trivial code, your code is going to have invariants. These invariants can be partially tested or they can be fully type-checked. The latter is better and cheaper, when available. Haskell makes the latter available far more often, so you don't have to pay for the former. This is not just useful for data structures, but code in general.

This post kind of sums it up for me. No, I'm not thinking about invariants. We're talking about writing a web app here. Typing is pretty meaningless when 99.9% of your data is just strings.

If 99.9% of your data is "just strings", you're probably Doing It Wrong.

Re: Frameworks Round 6

#107

Post by TylerE »

Peaker wrote: post #106
TylerE wrote: post #104

Earlier quoted context omitted.

This post kind of sums it up for me. No, I'm not thinking about invariants. We're talking about writing a web app here. Typing is pretty meaningless when 99.9% of your data is just strings.

If 99.9% of your data is "just strings", you're probably Doing It Wrong.

Again.... web app.

Re: Frameworks Round 6

#108

Post by agentS »

Peaker wrote: post #90
agentS wrote: post #76

Earlier quoted context omitted.

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

> I think people tend to underestimate the amount of time they spend on problems...

Again, the implication is that people who use languages with looser type-systems than Haskell spend lots of time dealing with the problems that you mention. In my experience, that is not the case. You can claim that I'm underestimating the impact of such bugs if you'd like.

> When you implement a red-black-tree, do you not spend any time testing your invariants?

Testing is, as far as I can tell, the reason that these problems don't come up. In the process of solving all of those problems I listed above, you tend to write a bunch of tests that exercise the same code that is run in production.

> 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 assure you that this transition is far less complete than you might think, and even when complete, will have more Java than Scala. Note that both of these languages allow shared mutable data, both allow null pointers.

> They all fail to scale well, both performance-wise and maintenance-wise. Statically-typed systems scale far better along both of these axis.

Oh, I agree. Go is statically-typed. However, you're advocating going even further along the spectrum, and I'm saying that going further brings diminishing returns, and starts costing you in terms of available engineers, and your productivity in writing code. I think Go occupies a good point along this spectrum, where I can write robust code without arguing with a compiler.

Re: Frameworks Round 6

#110

Post by VeejayRampay »

Peaker wrote: post #34
YcombRegBroken wrote: post #26

Earlier quoted context omitted.

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

No way in hell OCaml has "better concurrency than Go". Go is built around the concept. Not that OCaml is not an awesome language though, but that's just an outlandish statement.
Post reply on HN