Earlier quoted context omitted.
I guess you need to change the Hardware to "Win" to see it shining.
Java still beats it on Windows.
I don't see a framework-to-framework comparison. The .NET equivalent to a servlet is a "HTTP Handler"
Frameworks Round 6
71–80 of 135 posts
Re: Frameworks Round 6
#72I've followed yogthos' work on Luminus since the beginning.
It doesn't merit mention independently of Compojure. It's just some sane defaults for pedagogical reasons for getting started writing web apps on top of Compojure. It adds nor removes no runtime or anything else. As it currently exists, it's a Leiningen project template generator. That's about it.
Luminus is isomorphic, for the purposes of a benchmark, with Compojure.
I'm sure yogthos will be flattered when I tell him his web app templating thingy was included though.
Re: Frameworks Round 6
#73Earlier quoted context omitted.
Haskell (and most of the other languages mentioned) is exceptionally clever. This, above all else, is it's downfall. For me, especially when tasked with building a high productivity development team, clever code is a ticking time bomb. It's easy to write, but hard to maintain and modify. It requires more mental ram to analyze any given piece of code, and is much more difficult for multiple programmers to contribute t…
I disagree that Haskell is "clever". I think Haskell is "smart". Using "Maybe a" when you have a nullable value is smart, not "clever". It aids maintenance and readability, not hampers it. Using pattern matching is the same. Haskell builds on mathematicaly simplicity, which makes things hard to grasp at first. This may be mistaken for cleverness. Unless I'm misunderstanding you -- can you give an example of something…
I'm not a haskell expert (obviously), but the time it takes me to parse things like this is time I would rather spend reading 5-10x the number of lines and getting the meaning right away.
let loeb x = fmap ($ loeb x) x in
loeb [ (!!5), const 3, liftM2 (+) (!!0) (!!1), (*2) . (!!2), length, const 17]
I've seen cleaner and more readable code in production haskell, but this sort of thing happens enough that I'm very cautious.
Re: Frameworks Round 6
#74I've followed yogthos' work on Luminus since the beginning. It doesn't merit mention independently of Compojure. It's just some sane defaults for pedagogical reasons for getting started writing web apps on top of Compojure. It adds nor removes no runtime or anything else. As it currently exists, it's a Leiningen project template generator. That's about it. Luminus is isomorphic, for the purposes of a benchmark, with…
Sunglasses! Good to see a familiar name.
Incidentally, yogthos should be aware that Luminus was included: https://github.com/TechEmpower/FrameworkBenchmarks/pull/293
Re: Frameworks Round 6
#75Earlier 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…
> But for me all this seems quite biased towards small Frameworks/Platforms.
If one framework does less than another while still fulfilling the requirements of the test, then it ought to outperform that other framework, right? I don't see that as a bias; it's the expected result.
I said "does less" rather than "is smaller" there. I think that's an important distinction. It's theoretically possible for a framework to provide a feature at zero cost to users who don't use that feature (in responding to a given request). Some frameworks don't do that.
Re: Frameworks Round 6
#76Earlier quoted context omitted.
With respect, and I say this having experimented with Haskell, OCaml, any many other functional languages as well, just, no. Those languages come at a MUCH higher mental cost than go. Go is wonderful because writing it doesn't feel like I'm attempting a CompSci doctoral thesis. I can also say I have yet to see the Go runtime crash, and I am using in production. I also challenge your "better concurrency" claim.
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 you architect services to make them resilient to machine failure, how do you monitor services, how do you route logs, etc. With these problems, Haskell doesn't help here. Go doesn't help here either.
Second, there are operational problems. i.e. your FS might randomly corrupt some data you stored previously (remember to checksum), your caches might get out of sync (fun problem if you ever go multi-DC), your service has shoddy backoff and DDOS's a failing downstream service, etc. With these problems, Haskell doesn't help here. Go doesn't help here either.
Am I saying that there's no value to the fact that Haskell solves these at compile time? Of course not. Just that the relative amount of time that would save for me is not my deciding factor when picking a programming language.
Another way to think about it is that people have (I include myself in this category) written large-scale projects in dynamic languages which have all the problems you mentioned plus a few more. And yet, the developers at Twitter, or Facebook, or Reddit don't spend the vast majority of their time face-palming at type-errors or NPEs, or ConcurrentModificationExceptions. They have other concerns.
Re: Frameworks Round 6
#77Earlier quoted context omitted.
I disagree that Haskell is "clever". I think Haskell is "smart". Using "Maybe a" when you have a nullable value is smart, not "clever". It aids maintenance and readability, not hampers it. Using pattern matching is the same. Haskell builds on mathematicaly simplicity, which makes things hard to grasp at first. This may be mistaken for cleverness. Unless I'm misunderstanding you -- can you give an example of something…
I'm not a haskell expert (obviously), but the time it takes me to parse things like this is time I would rather spend reading 5-10x the number of lines and getting the meaning right away. let loeb x = fmap ($ loeb x) x in loeb [ (!!5), const 3, liftM2 (+) (!!0) (!!1), (*2) . (!!2), length, const 17] (btw, I have no idea what the hell this does. Something to do with spreadsheets, apparently. I found it on http://www.h…
I think the first paragraph of the page linked explains why that code is so impenetrable. You will not have to read or write Haskell like that, ever. Good find though! On a similar note, the Haskell community is amazing. You can learn absolutely everything between the Haskell wiki, freenode irc and hackage. How great is it that EVERY lib/package/framework is documented on hackage in exactly the same format? Very great. Coming back to JavaScript is a bummer :(
Re: Frameworks Round 6
#78Earlier 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).
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 never be popular. Go is gaining popularity quickly.
I think recommending Haskell to someone for a real project is bad advice from the above. Recommending Haskell to someone for self enrichment is another story, and I can get behind that one.
Re: Frameworks Round 6
#79What about Cobol on COGS?
Re: Frameworks Round 6
#80Earlier 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…
how about http://robfig.github.io/revel/ ? I just skimmed thru their manual and it seems quite promising
Revel is pretty great so far (I actually just made my first contribution yesterday!). Some important things it needs though: support for HTTPS, better DB support (some type of ORM, although gorp is sufficient for now), HTTP auth, and better template engine (currently uses the built-in Go "template" package which is meh). Those are the major things that come to my mind.