[Haskell-cafe] Message

[Alex Kropivny]

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 at 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 at 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 at 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 at 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 at 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 at live.com>
>>> >>>
>>> >>> Would you ever see yourself write a web application like Twitter or
>>> >>> Facebook in Haskell?
>>> >>>
>>> >>> _______________________________________________
>>> >>> Haskell-Cafe mailing list
>>> >>> Haskell-Cafe at haskell.org
>>> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>> >>>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> Haskell-Cafe mailing list
>>> >> Haskell-Cafe at haskell.org
>>> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>> >>
>>> >>
>>> >
>>> > _______________________________________________
>>> > Haskell-Cafe mailing list
>>> > Haskell-Cafe at 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 at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20111021/4e8b34a1/attachment.htm>