Hypothetical Haskell job in New York

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
80 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]

Tony Hannan
That's great to hear Bryan. I look forward to all of your projects you just mentioned, and work from others like you said, so one day soon we can built really high-performance web servers in elegant Haskell code.

I also like Reactive (or FRP in general) as a declarative alternative to message passing, and hope it will be high-performance as well.

Cheers,
Tony

2009/1/8 Bryan O'Sullivan <[hidden email]>
On Thu, Jan 8, 2009 at 1:07 PM, Manlio Perillo <[hidden email]> wrote:
 
Another example is the multipart parser:

-- | Read a multi-part message from a 'Handle'.
--   Fails on parse errors.
hGetMultipartBody :: String -- ^ Boundary
                 -> Handle
                 -> IO MultiPart
hGetMultipartBody b h =
   do
   s <- BS.hGetContents h
   case parseMultipartBody b s of
       Nothing -> fail "Error parsing multi-part message"
       Just m  -> return m

Yes, that's definitely on the scary side of things.

However, you don't have to go all the way to drinking the Iteratee Kool-Aid in order to write safer networking code that is still performant. Here are a few projects I'm actively working on in this area:
  • I'm adding epoll support to the threaded RTS. This is a necessity for server performance.
  • I've added support for sending and receiving lazy ByteStrings to Johan Tibbell's network-bytestring library. A quick benchmark with a toy HTTP server has shown this to be about 2x faster than writing ByteStrings to a Handle (i.e. 14,000 requests per second, vs 7,000).
  • I've got a continuation-based resumable parser combinator module for attoparsec in progress, which uses lazy ByteStrings for blazing performance. You can use this to write protocol parsers in a completely clean way, decoupled from the underlying network receive operations.
While much of this isn't quite ready for use yet, this just represents one person's work, and there are lots of people beavering away actively at corners of the problem space that interest them.

I actually think that we're very close to being in fantastic shape here. I'm working on a memcached client library that uses the above libraries, and it's faster than the absolute best C memcached client (libmemcached), while also far smaller and elegantly layered. As a community, we are developing many proofs that you can have beautiful code without sacrificing performance.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Low-level networking [Haskell not ready for Foo]

Thomas DuBuisson
In reply to this post by John Goerzen-3
Not all the data structures you need are there last I looked.  As you
could infer from my recent posts, one of my dozen future projects is
to add netinet/*.h like data structures to the Haskell network library
(i.e. TCP, IPv4, UDP headers with Binary instances).  This isn't to
say your task would be much more difficult, but it would be nice to
have a community wide definition available.

Tom

On Thu, Jan 8, 2009 at 10:50 PM, John Goerzen <[hidden email]> wrote:

> Andrew Coppin wrote:
>> John Goerzen wrote:
>>> On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote:
>>>
>>>> The number of applications requiring the implementation of a custom web
>>>> server is an insignificant fraction of the number of applications
>>>> requiring a messaging system. I don't think anyone would dispute
>>>> Haskell's ability to do low-level, raw networking, of the type that few
>>>> people actually need to do. It's the higher level stuff where there's a
>>>> huge amount of room for improvement.
>>>>
>>> I disagree on both points.
>>>
>>> Haskell has had somewhat of a deficit in the low-level networking
>>> stuff, not even supporting IPv6 in the standard stack until just
>>> recently.  (That is, things like AF_INET6 were not present.)
>>>
>>> I think it has pretty much caught up by now though.
>>>
>>
>> Any idea how I get Haskell to send ICMP ECHO packets? (And, obviously,
>> receive the replies.)
>
> SocketType claims to support Raw, which I think is the conventional
> means for doing this.  Whether all the infrastructure for that is there,
> I don't know.  I have never worked with raw sockets though, so I may be
> leading you down a dark mugger-laden alley here ;-)
>
> -- John
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hypothetical Haskell job in New York

Tony Hannan
In reply to this post by Tony Hannan
Well, I received 20 responses in 24 hours, many who would move from abroad to New York! I am very pleased with this number. Hopefully this will ease my boss's concern. But please continue to reply to me if you would be interested and haven't done so yet. The higher the number the more convincing the argument to my boss.

Thank you to all who replied. What a great mailing list. I will let you know if it actually turns into a real job opportunity.

Cheers,
Tony

On Wed, Jan 7, 2009 at 7:01 PM, Tony Hannan <[hidden email]> wrote:
Hello Haskellers,

I'm trying to convince my boss to use Haskell. His main concern is finding people who know Haskell when hiring. He is comfortable with Java because he knows he can always find a Java developer. So if I advertised we were looking for Haskell programmers in New York City, how many would respond? Please reply to this email if you would respond. Email me privately if you like and I will post the results to haskell-cafe later.
 
Our company is a startup CDN (http://en.wikipedia.org/wiki/Content_Delivery_Network) about 3 years old and doing well. You would hythothetically be one of 7 programmer who write all the software involved in a CDN including http server, dns server, monitoring, load balancing, customer and operator user interface, etc. The pay depends on experience but is good.

Thanks,
Tony


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Low-level networking [Haskell not ready for Foo]

Dominic Steinitz
In reply to this post by John Goerzen-3
John Goerzen <jgoerzen <at> complete.org> writes:
> > Any idea how I get Haskell to send ICMP ECHO packets? (And, obviously,
> > receive the replies.)
>
> SocketType claims to support Raw, which I think is the conventional
> means for doing this.  Whether all the infrastructure for that is there,
> I don't know.  I have never worked with raw sockets though, so I may be
> leading you down a dark mugger-laden alley here

Here's an example of a Haskell version of ping, now sadly bit-rotted.

Dominic.

http://haskell.org/networktools/src/ping/test.hs

http://haskell.org/networktools/src/ping/

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hypothetical Haskell job in New York

Manlio Perillo-3
In reply to this post by John Goerzen-3
John Goerzen ha scritto:
> On Thu, Jan 08, 2009 at 09:46:36PM +0100, Manlio Perillo wrote:
>> I'm speaking about servers, not clients.
>>
>> How much of pure Haskell internet servers are used in a production  
>> environment, in the "open internet" (and not in restricted LANs)?
>
> Does that really matter?  I tend to judge technology based on its
> merits for my work, not on who uses it.  

Well, testing a server is not easy.
You can have a server that works for you without problems, but in
different environment it gives problems.


 > [...]


Regard  Manlio Perillo
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]

Manlio Perillo-3
In reply to this post by Bryan O'Sullivan
Bryan O'Sullivan ha scritto:

> On Thu, Jan 8, 2009 at 1:07 PM, Manlio Perillo <[hidden email]
> <mailto:[hidden email]>> wrote:
>  
>
>     Another example is the multipart parser:
>
>     -- | Read a multi-part message from a 'Handle'.
>     --   Fails on parse errors.
>     hGetMultipartBody :: String -- ^ Boundary
>                      -> Handle
>                      -> IO MultiPart
>     hGetMultipartBody b h =
>        do
>        s <- BS.hGetContents h
>        case parseMultipartBody b s of
>            Nothing -> fail "Error parsing multi-part message"
>            Just m  -> return m
>
>
> Yes, that's definitely on the scary side of things.
>
> However, you don't have to go all the way to drinking the Iteratee
> Kool-Aid in order to write safer networking code that is still
> performant. Here are a few projects I'm actively working on in this area:
>
>     * I'm adding epoll support to the threaded RTS. This is a necessity
>       for server performance.

How easy is to add support for other methods, like poll, kqueue,
/dev/poll and Windows IOCP?


>     * I've added support for sending and receiving lazy ByteStrings to
>       Johan Tibbell's network-bytestring library. A quick benchmark with
>       a toy HTTP server has shown this to be about 2x faster than
>       writing ByteStrings to a Handle (i.e. 14,000 requests per second,
>       vs 7,000).

I personally like Nginx concept of chained buffers.
They are basically a linked list of buffers, where each buffer can be
1) an in memory buffer, where you have pointers to the start, end and
    current positions
2) file buffer, where you have a file descriptor and the current file
    offset

This is a nice abstraction, since, as an example, a file based buffer
can be sent to the network directly using sendfile.

I think it should fits well with ByteStrings.

>     * I've got a continuation-based resumable parser combinator module
>       for attoparsec in progress, which uses lazy ByteStrings for
>       blazing performance. You can use this to write protocol parsers in
>       a completely clean way, decoupled from the underlying network
>       receive operations.
>

This is interesting.
Writing clean protocol parsers is one of the things I think Haskell can
be great with.


> While much of this isn't quite ready for use yet, this just represents
> one person's work, and there are lots of people beavering away actively
> at corners of the problem space that interest them.
>

Well, I have no doubts that good networking can be done in Haskell.
The problem is time.
Erlang (and Twisted, from the Python world) have already years of use.

So, if I need to write *now* a network application, should I *invest* in
Haskell, or should I just *use* Erlang?

As a counter example: I really don't like SQL.
However I have to use it, if I don't want to re-implement a database by
myself.
The same can be said with Fortran.

 > [...]


Regards   Manlio
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hypothetical Haskell job in New York

John Goerzen-3
In reply to this post by Manlio Perillo-3
On Fri, Jan 09, 2009 at 01:06:44PM +0100, Manlio Perillo wrote:

> John Goerzen ha scritto:
>> On Thu, Jan 08, 2009 at 09:46:36PM +0100, Manlio Perillo wrote:
>>> I'm speaking about servers, not clients.
>>>
>>> How much of pure Haskell internet servers are used in a production  
>>> environment, in the "open internet" (and not in restricted LANs)?
>>
>> Does that really matter?  I tend to judge technology based on its
>> merits for my work, not on who uses it.  
>
> Well, testing a server is not easy.
> You can have a server that works for you without problems, but in  
> different environment it gives problems.

I completely understand that, as a sysadmin that has to maintain
mission-critical systems.  Unfortunately, it's also so often used as a
justification for using "whatever everyone else has".  So many people
buy Exchange for that reason, as an example.  Exchange has a pretty
long history of bugs that make it really unsuitable for use in the
Enterprise, yet people use it anyway because they think everyone uses
it.

A particularly amusing example is at
http://software.complete.org/software/issues/show/114 - my little
OfflineIMAP program appears to be able to take down entire Exchange
databases and force a restore from backup, because Exchange has a
hard-coded limit of 32k different mail header names *per
installation*, and OfflineIMAP generates one unique header each time
it uploads a message to the server.  If my program can do that
accidentally, imagine what someone with a will to do that could do.

Nobody would have ever tried Haskell, Python, or Perl in
mission-critical situations if they always thought like that.
Somebody has to be first, and I see no problem with it being us, as
long as we are confident of the outcome.

Part of the calculus has to be:

1) Can we test it under stress?

2) How confident are we that it will behave right under conditions we
can't test?  (Esp. malicious ones)

3) Can we fix it ourselves if it breaks?  How many others can fix it?

I really like Haskell because of #2.  While there is no 100%
guarantee, I feel better about Haskell not throwing a type error in
some obscure condition than I do about Python not doing so.  I also
like #2 because of the availability of both HUnit and QuickCheck.
Write your code right, and you can QuickCheck a significant part of
it.

-- John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]

John A. De Goes
In reply to this post by Austin Seipp

Hi Austin,

How do you know it's not your experience with FFI code that isn't biased? As far as I know, there has been no systematic attempt to document whether pure Haskell or FFI-based libraries are better designed and better maintained. Which means your statements come from your experience, and my statements come from my experience, and the truth is probably somewhere in between.

In my experience, FFI code is often based on bulk translation of C header files into the IO monad. It requires an exact version of a library to work (usually much older than the current), it does not compile out of the box, there's scant documentation, and very little high-level design has been imposed on the low-level C interface (may as well use C!). Exceptions to this rule, there are, but as I said before, my experience leads me to believe they *are* exceptions to a *general* rule.

Regards,

John

On Jan 8, 2009, at 3:47 PM, Austin Seipp wrote:

Excerpts from John A. De Goes's message of Thu Jan 08 12:14:18 -0600 2009:
But really, what's the point? FFI code is fragile, often uncompilable
and unsupported, and doesn't observe the idioms of Haskell nor take
advantage of its powerful language features.

This is a completely unfair generalization. The FFI is an excellent
way to interoperate with an extraordinary amount of external
libraries, and if you ask me, it's *worth* taking those pieces of C
code and wrapping them up in a nice, safe haskell interface. I will also
mention that Haskell has *the* simplest FFI I have ever used, which to
me only means it's easier to get it right (the fact that there are
customized *languages* like e.g. cython to make writing python
extensions easier makes me wonder.)

I suggest you take a look at the haskell llvm bindings - they are
extraordinarily well documented, and the high level interface uses
*many* haskell idioms that make the library safe and easy to use:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/llvm-0.4.2.0

This code most certainly takes advantage of powerful features and
idioms that only Haskell can provide. Please do not take your bad
experiences with a few crappy binding (or not even crappy bindings,
perhaps bindings that just aren't very abstract) and extend them to
the bindings that are excellent with a sweeping statement like that.

Austin
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]

John A. De Goes
In reply to this post by John Goerzen-3

My statements refer not to the FFI, but as I said, to "FFI code". FFI-based libraries seldom compile without excessive amounts of work, they're often poorly documented, and in general they seem to be maintained much less than pure Haskell libraries. The FFI is necessary, of course, but in general I view it as a bootstrapping process leading to pure Haskell libraries -- a crutch you have to live with until you can afford to pay the price of walking.

Regards,

John

On Jan 8, 2009, at 3:15 PM, John Goerzen wrote:

On Thu, Jan 08, 2009 at 11:14:18AM -0700, John A. De Goes wrote:
But really, what's the point? FFI code is fragile, often uncompilable
and unsupported, and doesn't observe the idioms of Haskell nor take
advantage of its powerful language features. Rather than coding through

That is an extraordinarily cruel, and inaccurate, sweep of FFI.

I've worked with C bindings to several high-level languages, and I
must say that I like FFI the best of any I've used.  It's easy to use
correctly, stable, and solid.  If anything, it suffers from
under-documentation.

The whole point of FFI is to bring other languages into the Haskell
fold.  So you can, say, talk to a database using its C library and
wind up putting the strongly-typed HaskellDB atop it.  Or you can
write an MD5 algorithm in C and make it look like a regular Haskell
function.

You can indeed fit a square peg in a round hole, if you pound hard
enough. That doesn't mean it's a good thing to do.

And with that, I fully agree.

-- Joh


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]

John A. De Goes
In reply to this post by John Goerzen-3
> On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote:
>>
>> The number of applications requiring the implementation of a custom  
>> web
>> server is an insignificant fraction of the number of applications
>> requiring a messaging system. I don't think anyone would dispute
>> Haskell's ability to do low-level, raw networking, of the type that  
>> few
>> people actually need to do. It's the higher level stuff where  
>> there's a
>> huge amount of room for improvement.
>
> I disagree on both points.
>
> Haskell has had somewhat of a deficit in the low-level networking
> stuff, not even supporting IPv6 in the standard stack until just
> recently.  (That is, things like AF_INET6 were not present.)
>
> I think it has pretty much caught up by now though.

If you think Haskell has caught up by now, then you DO NOT disagree  
with my statement that "[no one] would dispute Haskell's ability to do  
low-level, raw networking."

Which makes me wonder what you mean by, "I disagree on both points."

> On the other hand, I see nothing in Haskell that would prevent its use
> for any of your purposes.  There are numerous high-level web
> infrastructures already.  Perhaps they are more or less suited to your
> needs, but that's a library issue, not a language issue.

In other words, to quote myself, "it's the higher level stuff where  
there's a huge amount of room for [library] improvement."

Nothing in the Haskell language prevents its use for high-level  
networking. But the sad fact of the matter is that there is no library  
support for it. So applications that need such networking today are  
better off written in Erlang.

Regards,

John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]

John A. De Goes
In reply to this post by Creighton Hogg-4

If you're looking for a project to take on, I would suggest starting with the following:

A high-level, type-safe AMQP client written in 100% Haskell, which provides a clean way of handling hundreds of unique message types.

Then it would be possible to hook it up to any AMQP broker (most likely RabbitMQ). There are logical steps beyond the above (an embedded Haskell broker), but the above project is far from trivial. And the main undertaking, I think, consists not in coding to the spec (for which there is some help; a JSON representation of the AMQP specification can be processed and used to emit language-specific code), but in finding a design that works well in Haskell.

Regards,

John

On Jan 8, 2009, at 1:16 PM, Creighton Hogg wrote:

On Thu, Jan 8, 2009 at 2:02 PM, John A. De Goes <[hidden email]> wrote:

On Jan 8, 2009, at 12:56 PM, Tim Newsham wrote:

You replied to someone discussing using Haskell at a CDN to implement
things like web servers by saying that Haskell wasn't suitable for
the task.


That is incorrect. I replied to Achim's message asking for elaboration on
Haskell's unsuitability. It was a convenient point to discuss Haskell's
networking deficiencies.

Part of the problem I'm having with this discussion, though, is that
it's still not clear to me what critical features are lacking.  I know
you've said Haskell doesn't have anything quite like the Erlang OTP
library, but that doesn't really help me much.  I've only looked a
little at OTP & I don't think I understand what you get from its
behaviors that you don't get from Control.Concurrent + mtl, i.e.
various forms of state & error handling independent of the concurrency
underneath.

Can you elucidate a bit more?  I don't want the conversation to degenerate.


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]

John A. De Goes
In reply to this post by Bryan O'Sullivan

You must be referring to "erlang-0.1", an alpha release of a package that impersonates an Erlang node. 

Which is surely useful to someone, somewhere, but is not useful to write a messaging application.

Regards,

John

On Jan 8, 2009, at 4:17 PM, Bryan O'Sullivan wrote:

On Thu, Jan 8, 2009 at 10:06 AM, Don Stewart <[hidden email]> wrote:
Note that there even exists an FFI binding to Erlang for Haskell, so
that Haskell nodes can seamlessly interact with other nodes speaking
Erlang's protocol format.

Actually, the erlang package doesn't use the FFI: it speaks the Erlang wire protocol to send and receive terms.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]

John A. De Goes
In reply to this post by Bryan O'Sullivan
On Jan 8, 2009, at 4:34 PM, Bryan O'Sullivan wrote:
> I actually think that we're very close to being in fantastic shape  
> here.

I think that's Haskell zeal speaking. :-)

Not that I don't appreciate your zeal (I do), and I'm definitely  
excited about the stuff you're working on, but we're a long way from  
having stable, mature, well-designed libraries that are fit for  
production use in high-level messaging applications. In this niche  
(and quite a few other networking-related niches), Erlang is the clear  
winner, at least for the immediate future (in the long-term, the  
purity of Haskell could lead to some high-performance, robust  
approaches not possible for Erlang).

Regards,

John

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]

David Leimbach
In reply to this post by Manlio Perillo-3

So, if I need to write *now* a network application, should I *invest* in Haskell, or should I just *use* Erlang?

You're in Haskell-Cafe... the bias is there already for Haskell.

Personally, I don't have experience doing network applications in Haskell, but I've got about a year's worth or more using Erlang, so for me it's a pretty easy choice, and I wouldn't pick Haskell today.  

(hearing boos in the background as I type this...)

However, I would invest in learning to use Haskell, because my experience with Erlang has been that it really is pretty great, and has lovely features, like the ability to shell into a running process and poke around if something seems not quite right, or even to ssh into it if you run the right services.  Plus there's tons of stuff pre-written for network applications that just comes with the Erlang distribution, meaning there's nothing else to install.... but even after all of that, I miss the type safety of Haskell, as it's really painful to do this in erlang

function(T1, T2, T3) when is_list(T1) and is_integer(T2) and is_integer(T3) ->
    ....function body

Even if you have a list, you don't know "what of" so you never really get the guarantees that you get when a Haskell program successfully compiles...  That peace of mind is not easily won in Erlang, except by lots of testing.

Dave
 


As a counter example: I really don't like SQL.
However I have to use it, if I don't want to re-implement a database by myself.
The same can be said with Fortran.

> [...]


Regards   Manlio
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]

John Goerzen-3
In reply to this post by John A. De Goes
John A. De Goes wrote:
>
> My statements refer not to the FFI, but as I said, to "FFI code".
> FFI-based libraries seldom compile without excessive amounts of work,
> they're often poorly documented, and in general they seem to be

Examples?

I maintain a couple of FFI libraries, and strive to have them just work
with one line of calling cabal.  There are plenty of other FFI libraries
that also work that way.  In fact, I don't really notice a difference
these days, at least with the FFI libraries I've used.

In any case, apt-get usually grabs stuff I want anyhow.

I don't really see why the underlying details of an implementation (C or
Haskell) would necessarily correlate with levels of documentation, and
it doesn't seem to for me anyhow.

> maintained much less than pure Haskell libraries. The FFI is necessary,
> of course, but in general I view it as a bootstrapping process leading
> to pure Haskell libraries -- a crutch you have to live with until you
> can afford to pay the price of walking.

Well, you pretty much always have to get down to the C level on a *nix
platform at some point, anyhow.  You've got to make syscalls somewhere.

I don't think FFI is so evil.  There is value in avoiding wheel
reinvention, too.  If zlib already works great, why re-invent it when
you can easily just use what's there?

-- John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]

Thomas DuBuisson
In reply to this post by John A. De Goes
John A. De Goes said:
> If you're looking for a project to take on, I would suggest starting with [AMQP]

See:
http://www.reddit.com/r/haskell_proposals/comments/7ihpt/amqp_client/

This isn't a new proposal, not to imply you thought so.  If you have a
need for such a library please start working or start a team.  Short
of that, expressing your interest (or perhaps subsequent projects
requiring AMQP) in our somewhat new "Proposed Projects" reddit
community might draw attention to this cause.

Tom
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]

Creighton Hogg-4
In reply to this post by John A. De Goes
2009/1/9 John A. De Goes <[hidden email]>:

>
> If you're looking for a project to take on, I would suggest starting with
> the following:
>
> A high-level, type-safe AMQP client written in 100% Haskell, which provides
> a clean way of handling hundreds of unique message types.
>
> Then it would be possible to hook it up to any AMQP broker (most likely
> RabbitMQ). There are logical steps beyond the above (an embedded Haskell
> broker), but the above project is far from trivial. And the main
> undertaking, I think, consists not in coding to the spec (for which there is
> some help; a JSON representation of the AMQP specification can be processed
> and used to emit language-specific code), but in finding a design that works
> well in Haskell.
<snip & reorder>
I apologize, but my question was geared more towards understanding
what high-level OTP-like libraries Haskell is lacking, not full blown
applications that haven't been written in Haskell.  It sounded like
you had some specific insight into this.

Cheers,
Creighton
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Low-level networking [Haskell not ready for Foo]

Andrew Coppin
In reply to this post by Thomas DuBuisson
Thomas DuBuisson wrote:
> Not all the data structures you need are there last I looked.

This was my conclusion as well.

As with most network libraries I've seen, TCP works just great, and
anything else... tough? (I couldn't even see UDP last time. Have I
missed something?)

> As you
> could infer from my recent posts, one of my dozen future projects is
> to add netinet/*.h like data structures to the Haskell network library
> (i.e. TCP, IPv4, UDP headers with Binary instances).  This isn't to
> say your task would be much more difficult, but it would be nice to
> have a community wide definition available.
>  

That would, indeed, be nice.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Low-level networking [Haskell not ready for Foo]

Andrew Coppin
In reply to this post by Dominic Steinitz
Dominic Steinitz wrote:

> John Goerzen <jgoerzen <at> complete.org> writes:
>  
>>> Any idea how I get Haskell to send ICMP ECHO packets? (And, obviously,
>>> receive the replies.)
>>>      
>> SocketType claims to support Raw, which I think is the conventional
>> means for doing this.  Whether all the infrastructure for that is there,
>> I don't know.  I have never worked with raw sockets though, so I may be
>> leading you down a dark mugger-laden alley here
>>    
>
> Here's an example of a Haskell version of ping, now sadly bit-rotted.
>
> Dominic.
>
> http://haskell.org/networktools/src/ping/test.hs
>  

I have a worrying feeling this might be too Unix-specific to work on
Windows. But I guess it's a start...

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Low-level networking [Haskell not ready for Foo]

John Van Enk
In reply to this post by Andrew Coppin
I've managed to get UDP NAT traversal working in my personal project. I haven't really had issues with the Networking libraries at all (except that htons and htonl aren't where i expected them to be... and yes, i did actually need them...)

/jve


On Fri, Jan 9, 2009 at 1:18 PM, Andrew Coppin <[hidden email]> wrote:
Thomas DuBuisson wrote:
Not all the data structures you need are there last I looked.

This was my conclusion as well.

As with most network libraries I've seen, TCP works just great, and anything else... tough? (I couldn't even see UDP last time. Have I missed something?)


As you
could infer from my recent posts, one of my dozen future projects is
to add netinet/*.h like data structures to the Haskell network library
(i.e. TCP, IPv4, UDP headers with Binary instances).  This isn't to
say your task would be much more difficult, but it would be nice to
have a community wide definition available.
 

That would, indeed, be nice.


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
1234