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

The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

blog.dbpatterson.com

Post reply on HN
Print view View original

81–90 of 104 posts

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#81

Post by lincolnq »

zoul wrote: post #49
tikhonj wrote: post #35

Earlier quoted context omitted.

Why is that surprising? Haskell is a compiled language with a very clever optimizing compiler, so it tends to be pretty fast by any standard. On top of this, it has recently had some improvements to its IO manager which is particularly important for web servers. Ruby, on the other hand, is notoriously slow.

Performance isn’t measured just by the language tools, it depends on the whole stack. It’s quite probable that the Ruby/Rails stack is better suited to high-performance sites simply because it has more installations and the kinks have been worked out.

I agree that the priors would suggest that you are correct, however, let me give some evidence to update you:

The Warp web server for Haskell is the fastest Web application server that exists. http://steve.vinoski.net/pdf/IC-Warp_a_Haskell_Web_Server.pd... [pdf, but easy to read] -- in the comparison on page 2, php handled 3400 requests per second, and Warp 81000.

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#82

Post by mightybyte »

getsat wrote: post #78
BadCRC wrote: post #63

I really hope Haskell/Snap starts getting picked up by everyday web developers so someone can start exposing ridiculous things like: > 11111111111111111111111111111 - (length []) => 1729917383

Can someone explain what is happening in this example? I'm learning Haskell right now and this makes no sense.

It's essentially the same thing as doing:

    > 11111111111111111111111111111 :: Int
Numeric literals are automatically treated as Num instances, so when you subtract (length []) which is an Int, the literal is treated as an Int. In this case, it triggers an overflow condition, something that programmers understand well and have been dealing with from the earliest days.

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#83

Post by lincolnq »

getsat wrote: post #78
BadCRC wrote: post #63

I really hope Haskell/Snap starts getting picked up by everyday web developers so someone can start exposing ridiculous things like: > 11111111111111111111111111111 - (length []) => 1729917383

Can someone explain what is happening in this example? I'm learning Haskell right now and this makes no sense.

    Prelude> :t 11111111111111111111111
    11111111111111111111111 :: Num a => a
    Prelude> :t (length [])
    (length []) :: Int
    Prelude> 11111111111111111111111111111 - (length [])
    1729917383
    Prelude> 1111111111111111111111111111 - 0
    1111111111111111111111111111
    Prelude> 1111111111111111111111111111 - fromIntegral (length [])
    1111111111111111111111111111
    Prelude> 11111111111111111111111111111 :: Int
    1729917383
"Int" is the machine-length integer type. "Integer" is the unbounded, but slower integer type ("bigint" in other languages). In Prelude, "length" always returns an Int, assuming that the length of a list will never be bigger than 232.

Haskell interprets numeric literals as the typeclass (Num a => a), meaning any member of the typeclass Num can be constructed using these literals. Int is one such type, and causes wraparound when it constructs an instance using the typeclass.

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#84

Post by masklinn »

riffraff wrote: post #50
masklinn wrote: post #34

Earlier quoted context omitted.

I don't know: 1. having nullable references by default strikes me as a bigger issue 2. I don't see any reason I'd want to subclass String, actually (though I could see wanting to create an alternate implementation e.g. ropes-based). So String being a final class makes perfect sense as far as I'm concerned (unless it were an interface or some sort of "proxy" class as is often done in Cocoa). On the other hand, I'd giv…

how would a nominally different string type be better than wrapping the string ? I mean I understand why having a Name, ZipCode or UUID stringish class helps ensure program correctness, I do not understand (out of ignorance) how it would improve your code vs a wrapper.

> how would a nominally different string type be better than wrapping the string ?

* It is significantly less verbose, therefore simpler and more likely to be used at all. And less error-prone

* It can provide string APIs working on itself (either by default or through the aliasing declaration) precluding the need to manually re-implement things like comparisons or printing

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#85

Post by SkyMarshal »

lincolnq wrote: post #75
SkyMarshal wrote: post #70

Earlier quoted context omitted.

>Agree with this 100%. I think dynamically typed languages are a transitional technology we'll mostly leave behind as the kinks get worked out of modern type systems. While my favorite language right now is Haskell due to its sophisticated type system and ambitious design goal of enabling engineers to coral and isolate error-causing code into monads, I have to disagree. Dynamic languages can be looked at as the next…

Wow, interesting perspective. Let me attempt to summarize what you said: When compilers/runtimes become smart enough, you won't need a static type system, because the runtime one will catch all your errors. Here's why I think it's wrong: Catching errors is not something that I want done at runtime.

Not all your errors, dynamically typed languages still require testing.

And I agree, I tend to prefer type systems like haskell that offer better compile time assurance than testing, but my point is there's a large contingent of programmers who don't, and who drive uptake of increasingly automated and abstracted dynamically typed languages (this isn't a prediction, but an observation of how things already are).

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#86

Post by danneu »

carterschonwald wrote: post #66
danneu wrote: post #26

I've been learning Haskell on the side for a while and was hoping for something more after reading the title, but the post pretty much just points out a few preferences that OP has. I spend very little time in Rails hung up on any of the issues expressed. With some experience with frameworks like Express/Noir/Sinatra, I find that Rails is productive for me because of (A) convention and (B) getting common things done…

I'm slightly confused by this. Is it not the case with rails that many of the .rb files are generated via rails? I think you're over thinking / pessimizing what happens with haskell code. 1) for any self contained project (library or executable) in haskell, the directory structure determines the module names. if you're wondering how the functions imported from the Foo.Bar module are implemented you simply go to the s…

I mean to specify higher level design conventions, as in the structuring decisions you'd have to make in a non-trivial app.

For instance, my experience with Express. The popular Peepcode screencast makes a Django'esque `apps` directory and modularizes the granular components of the entire app. Other people make an `app` directory and model the familiar Rails MVC. Some people contain controller logic in the router. Some people export routes from smaller files into app.js under a `//routes` comment. Sometimes the connection to the database is bootstrapped when the server starts in app.js. Sometimes the database is accessed from each model. Sometimes the database is accessed from each route. And you're guaranteed to have to dig into every required file to see how they exposed its API. Did they module.exports the entire object? Or did they individually export each public method?

See, I'm not criticizing unopinionated frameworks. They're for people that are opinionated and want to write the code that glues their opinionated structure together. Or for apps small enough to get by without deliberated structure.

But in a discussion about productivity, perhaps there's something to be said when people with experience making non-trivial apps have corroborated conventions and practices for a community to share.

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#87

Post by yxhuvud »

mtrimpe wrote: post #33
chc wrote: post #19

Earlier quoted context omitted.

The thing is, it's not that straightforward. It's not about avoiding type errors that would have cropped up in Ruby, but about getting the type system to encode as much of your program's semantics as possible. For example, in Ruby, you use strings and symbols for a lot of disparate things. In Haskell, you'd introduce a type for each purpose to encode your intent in a way the compiler understands†. In Haskell, you're…

I agree very much. As far as I'm concerned Java's biggest failure, orders of magnitude worse than all others, is to make java.lang.String a final class.

Biggest failure? try Integer(100) == Integer(100) and Integer(200) == Integer(200)

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#88

Post by yxhuvud »

lincolnq wrote: post #81
zoul wrote: post #49

Earlier quoted context omitted.

Performance isn’t measured just by the language tools, it depends on the whole stack. It’s quite probable that the Ruby/Rails stack is better suited to high-performance sites simply because it has more installations and the kinks have been worked out.

I agree that the priors would suggest that you are correct, however, let me give some evidence to update you: The Warp web server for Haskell is the fastest Web application server that exists . http://steve.vinoski.net/pdf/IC-Warp_a_Haskell_Web_Server.pd... [pdf, but easy to read] -- in the comparison on page 2, php handled 3400 requests per second, and Warp 81000.

Uh. This doesn't make any sense whatsoever.

As to why, here is a hint: The three most common webservers in the world are Apache, nginx and IIS. Yet are any of those even mentioned in that paper? NO.

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#89

Post by lincolnq »

yxhuvud wrote: post #88
lincolnq wrote: post #81

Earlier quoted context omitted.

I agree that the priors would suggest that you are correct, however, let me give some evidence to update you: The Warp web server for Haskell is the fastest Web application server that exists . http://steve.vinoski.net/pdf/IC-Warp_a_Haskell_Web_Server.pd... [pdf, but easy to read] -- in the comparison on page 2, php handled 3400 requests per second, and Warp 81000.

Uh. This doesn't make any sense whatsoever. As to why, here is a hint: The three most common webservers in the world are Apache, nginx and IIS. Yet are any of those even mentioned in that paper? NO.

Hm, you may be right. The methodology to arrive at these results in the paper is not given at all (as far as I can tell).

However I suspect that the three you listed would not be benchmarked on their own, as they are not application servers, just frontends. It would be more reasonable to benchmark Apache+mod_wsgi or whatever, and it would be nice to see that on the graph.

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#90

Post by joeyh »

zopa wrote: post #67
danneu wrote: post #26

I've been learning Haskell on the side for a while and was hoping for something more after reading the title, but the post pretty much just points out a few preferences that OP has. I spend very little time in Rails hung up on any of the issues expressed. With some experience with frameworks like Express/Noir/Sinatra, I find that Rails is productive for me because of (A) convention and (B) getting common things done…

I think you've stated the main Snap vs. Yesod distinction in Haskell-land: "here are some tools" versus "do this." There's advantages to each approach, and luckily there are solid Haskell frameworks for both.

Maybe Sorta. Most of Yesod is also reusable libraries, for example I've used Hamlet to generate HTML without using any of the rest of Yesod.
Post reply on HN