Define "better". Probably it wouldn't be more secure because both would be scrutinized and production-tested about the same. It would protect us against some common C errors but might make us vulnerable to "common" Haskell vulnerabilities. You really can't say.
It probably would be slower though, which is kind of a big deal for webservers and the like.
> It probably would be slower though, which is kind of a big deal for webservers and the like.
More critically, it would only be useful to Haskell code. Haskell, unless C, cannot be embedded. Having a version in Rust - which does not rely on the runtime - ought to be safe from this kind of issue (baring any problem in Rust itself) while being still embeddable from external code. It would still be somewhat slower than C, and of course Rust is far from mature.
Not in only could be embedded, but also compiled into dynamically linked library.
(Shameless plug) I've collected examples of this here: https://github.com/drdaeman/haskell-library-ffi-example
The nice thing about this example is that you only need GHC to create the shared library, and then GCC can do the rest with just the .so file produced.
Doesn't Haskell compile first to C and then to native?
Not since GHC 7.0: http://www.haskell.org/ghc/docs/7.4.2/html/users_guide/code-...
Re:TLS/SSL implementation in Haskell
by stefantalpalaru on Wednesday April 09, 2014 @06:08AM
(#7558507)
I was unaware of that. Looking a bit deeper into it, it looks pretty involved as soon as you want to do something non-trivial with it.
Ok, but if it were vetted as much as openssl, it would probably be much better, yes?