Yes I did, in detail. There are two trivial solutions I like:

1. The BERT library (http://bert-rpc.org/) uses Erlang terms for the protocol, and has straightforward mappings to Haskell equivalents.
- Pros: trivial on both sides, Erlang terms are really good primitives to build a protocol from
- Cons: Erlang likes using large (5 to 10 size) tuples and Haskell doesn't, protocol needs to take that into account

2. JSON over HTTP, Erlang's the server Haskell's the client.
- Pros: discoverable, flexible, readable, language agnostic.
- Cons: I don't really know how to use Haskell JSON libraries + which ones are good, and good REST API design can be tricky.

For higher performance there are other options, but these are the ones I like most. I used 1 to decent effect when using QuickCheck to test an Erlang system.

On Fri, Oct 21, 2011 at 8:02 AM, Yves Parès <limestrael@gmail.com> wrote:
That's interesting, have you ever worked on interfacing Erlang with Haskell?

BTW, Twitter switched to Scala, so obviously their initial choice of Ruby end up invalidated.


2011/10/21 Alex Kropivny <alex.kropivny@gmail.com>
Let's look at this from a high, project management level. Twitter ran on... Ruby initially? Facebook ran on PHP.

Immediately this tells me that programming language choice wasn't a factor in their success. One succeeded in building a large throughput system with a "slow" language, the other succeeded in building a massively popular website with a bad one.

What hard problems did they have to solve? 

Twitter had to deal with scalability, distribution, and massive throughput. These are hard problems on their own, and are non-trivial even in languages tailor made to handle them. (Although using Erlang would make things a good deal easier.)

Facebook is not a technical problem at all. There are interesting challenges hidden within (ad targeting and friend feed optimization) but they're tiny, isolated components. Rapid development and prototyping of features help Facebook, but if the features are easy CRUD stuff it's perfectly cost effective to hire a pile of PHP developers to do them.


One has problems that are hard regardless of tool choice, the other has no hard problems at all. No Haskell needed, use whatever language you can outsource overseas.



With that in mind. Using Haskell gives you an edge, for most problems, even the ones with poor libraries. If you can get the programmer manpower you need, it is a clear advantage over your competition.

Your startup may not need that advantage - as Facebook retrospectively didn't - but you don't know that when just starting out. If Facebook went deep into user behaviour analysis and newsfeed optimization, the way OkCupid has with dating, Haskell would suddenly stand out.

If you need every advantage you can get, you use the best tools for the job. Haskell is one of the best and shiniest - I personally would use Erlang for any embarrassingly parallel parts of the service and do the rest in Haskell.


On Fri, Oct 21, 2011 at 1:00 AM, Matti Oinas <matti.oinas@gmail.com> wrote:
I don't think I'm going to write next twitter or facebook but yes, it
is on my TODO list. If such an applications can be written with
languages like PHP then why not. Can't think of any language that is
worse than PHP but still there are lots of web applications written
with that. Even I have written many using PHP.

Why I would use Haskell? To see if it is better option to that problem
than other languages.

I have allready installed Yesod but for now I don't have enough time
to work on this project. After 6 months the situation should be
different.

2011/10/21 Michael Snoyman <michael@snoyman.com>:
> This is clearly a job for node.js and the /dev/null data store, since
> they are so web scale~
>
> Less sarcasm: I think any of the main Haskell web frameworks (Yesod,
> Happstack, Snap) could scale better than Ruby or PHP, and would use
> any of those in a heartbeat for such a venture. I'd personally use
> Yesod.
>
> I think data store would be a trickier issue. I'd likely use one of
> the key/value stores out there, possibly Redis, though I'd really need
> to do more research to give a real answer.
>
> Michael
>
> On Fri, Oct 21, 2011 at 9:42 AM, Yves Parès <limestrael@gmail.com> wrote:
>> Wow, controversial point I guess...
>> I would add: and if yes, what would you use and why?
>>
>> 2011/10/21 Goutam Tmv <vo1d_pointer@live.com>
>>>
>>> Would you ever see yourself write a web application like Twitter or
>>> Facebook in Haskell?
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



--
/*******************************************************************/

try {
   log.trace("Id=" + request.getUser().getId() + " accesses " +
manager.getPage().getUrl().toString())
} catch(NullPointerException e) {}

/*******************************************************************/

This is a real code, but please make the world a bit better place and
don’t do it, ever.

* http://www.javacodegeeks.com/2011/01/10-tips-proper-application-logging.html *

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe