On Mon, Apr 18, 2011 at 07:55:57AM -0400, Mike Meyer wrote: > On Mon, 18 Apr 2011 12:56:39 +0200 > Ertugrul Soeylemez <e...@ertes.de> wrote: > > > > You also don't need Emacs/Vim, if all you want is to write a simple > > plain text file. There is nothing wrong with concurrency, because you > > are confusing the high level model with the low level implementation. > > Concurrency is nothing but a design pattern, and GHC shows that a high > > level design pattern can be mapped to efficient low level code. > > Possibly true. The question is - can it be mapped to a design that's > as robust and scalable as the ones I'm used to working on?
I have not written any such server so take my response with a pinch of salt but I believe that the forkIO based solution does indeed scale to 10K clients. Internally the runtime uses epoll or kqueue to simulate the concurrency, so I don't see why it should be slower. May be you can check with the developers of Network.Wai or the Happstack server developers. They might be in a better possition to explain. > [snip] > > Perhaps Haskell is the wrong language for you. How about programming in > > C/C++? I think you want more control over low level resources than > > Haskell gives you. But I suggest having a closer look at concurrency. > > Personally, I don't want to have to worry about low-level resources, > or even concurrency. Having to do so feels to much like having to > explicitly allocate and free memory, or worry about register > allocations. But if I have to do those things to get robustness and > scalability until the languages start being able to deal with it, then > I need the RTS to get out of the way and let me do my job. I think it would be good idea to prototype what you want to do and have a try. Most likely I would think you would be surprised with the efficiency. > If I'm using a value that needs protection from concurrent access > without providing that protection, I want the system give me an > error. At run-time is acceptable, but compile time is better. Try STM's. They are great abstractions for shared states. Regards ppk _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
