Thoughts regarding use of Rust and Haskell for building a blockchain

[ataraxiaceleste]

What are your thoughts regarding Haskell and Rust? Do you think it allows us to be productive while writing high-quality code? What are the programmers most common experiences while using these languages especially in the field of Blockchain development?

[HeRetiK]

I think Rust might have a chance to eventually become a viable alternative to native C/C++ programming over the next few years, but I'm afraid Haskell will remain more of a niche thing. I'm mostly basing this assumption on Rust having a larger following then Haskell despite being the younger of the two, also from what I've gathered Rust appears to be much more performant which for crypto is not unimportant.

In general it would be interesting to see a shift towards functional programming not only in crypto but in other fields as well. Having only meddled with functional programming on pet projects I can't say much on how well it scales with a growing codebase though.

[pooya87]

a high quality, performant,... code is not about what language you choose but it is all about your personal skills at writing code in that language. you can write crappy code that runs extremely slowly in C or C++ while writing something that runs very fast in python for instance.
generally speaking there is no good answer to the question about whether language x is good for doing y. in most cases they are unless you can't write the code for doing y properly. the blockchain technology is no different.

[amishmanish]

Rust and Haskell as Functional Programming languages are supposed to be free of the potential exploits and bugs that Turing completeness entails. While reading about Simplicity, i came across this paradigm of functional programming, which btw explains the unfamiliar "types" and combinators in simplicity. (Unfamiliar to me who uses programming tools like C and Python for rudimentary tasks and not for building products per se).

I am unable to find the link to a talk being given by a company founder about this who said that with FP, you wouldn't risk things like the parity bug. I am still learning more about it and to me the whole concept currently sounds a bit esoteric with the interesting history behind lamba calculus. Alonzo Church who invented lamba calculus was the doctoral guide to Alan Turing. While Turing's programming paradigm with Turing machine became dominant, Alonzo's FP paradigm remained niche and has only recently begun to get traction.

EDIT1:

[ABCbits]

There's a discussion about using Rust for Bitcoin reference implementation at https://bitcointalk.org/index.php?topic=5192509.0

While i don't know much about Rust and Haskell, AFAIK it'd be hard find developer or contributor who're experienced in Rust rather than C or C++.

[tromp]

Haskell would be great for concisely expressing the consensus model, e.g. a function

validWork :: [Block] -> Either String Int

that either returns an error message in case of an invalid history, or the cumulative difficulty in case of a valid history,
written for maximum clarity rather than maximal performance,
could serve as a formal specification of the consensus model.

[HeRetiK]

While i don't know much about Rust and Haskell, AFAIK it'd be hard find developer or contributor who're experienced in Rust rather than C or C++.

Yeah, it's a bit of a chicken-egg problem unfortunately.

Without experienced developers around, companies have little reason to add Rust or Haskell to their stack. Without companies hiring Rust or Haskell developers, the opportunity to become experienced in either language is very limited. There's probably a bigger market for Ada, COBOL... maybe even Fortran.

[ataraxiaceleste]

I recently came across this ( https://medium.com/@johncantrell97/how-i-checked-over-1-trillion-mnemonics-in-30-hours-to-win-a-bitcoin-635fe051a752 ) very cool "experiment" this person did by checking over 1 Trillion mnemonics in 30 hours to win a BTC. According to him, to test a single mnemonic we would have to generate a seed from the mnemonic, master private key from the seed, and an address from the master private key. He basically wrote a CPU benchmark tool, version in Rust to benchmark performance of a CPU solver to guage how long it would take to solve on a CPU for a certain number of unknown words.  

He even open sourced all of the projects he used to solve this problem.

[pooya87]

I recently came across this ( https://medium.com/@johncantrell97/how-i-checked-over-1-trillion-mnemonics-in-30-hours-to-win-a-bitcoin-635fe051a752 ) very cool "experiment" this person did by checking over 1 Trillion mnemonics in 30 hours to win a BTC. According to him, to test a single mnemonic we would have to generate a seed from the mnemonic, master private key from the seed, and an address from the master private key. He basically wrote a CPU benchmark tool, version in Rust to benchmark performance of a CPU solver to guage how long it would take to solve on a CPU for a certain number of unknown words. 

He even open sourced all of the projects he used to solve this problem.

it would have been interesting if he wrote all of it in Rust instead of only the initial very slow solution then end up using all the libraries written 100% in C. the final solution is basically a wrapper written in Rust around those C libraries!

[NotATether]

it would have been interesting if he wrote all of it in Rust instead of only the initial very slow solution then end up using all the libraries written 100% in C. the final solution is basically a wrapper written in Rust around those C libraries!

I think the ability to do that depends on whether Rust is able to interface with other computing hardware besides CPUs. Particularly the libsecp256k1 code written in OpenCL wouldn't be a pure Rust implementation with simply a driver library written in Rust. Rather, OpenCL bindings to Rust need to exist for any OpenCL Rust program to be possible. Same applies to any other GPU/FPGA computing language.

[gmaxwell]

Performance and memory usage are both security critical in consensus systems.  It's difficult (impossible?) to write Haskell which is all three performant, predictable in its memory usage, and idiomatic-- at least for some sufficiently strict requirements in performance and memory usage.

Rust is a lot like C++.  In theory, it's easier to write rust code that lacks particular classes of bugs than in C++.  However, no one using C++ uses the entire language and the various subsets people use also largely avoid various kinds of bugs. Not as rigorously as rust, particularly because its hard to verify you're using the subset of C++ you're intending to use.

In Bitcoin we've found that the kind of bugs that rust guarantees the absence of have been uncommon.

I've personally found that the rust code I've encountered online has often been low quality to extremely low quality-- often throwing panics on the slightest unexpected input or usage, or suffering from incorrect results due to integer wraparound (which in theory debug mode would catch, but it runs so slow as to be completely unusable on many codebases).  I'm unsure if this is a property of the language itself (e.g. does the syntax lead to greater faults), user's expectations of the language (sloppy work because they expect things to be 'safe'), or the user/application (e.g. are people that redo stuff "but in rust" less experienced programmers?).

Given that experience I would not place a bet right now that rust currently lowers the rate of serious defects in large programs developed by experienced teams compared to C++ with modern practices. However, if I had to use software written by inexperienced developers I suppose I would probably prefer they use rust to C++...

The rust ecosystem is also immature and unstable-- it's not uncommon that any random code you get requires some bleeding edge new compiler. Rust also largely imitates the extremely security-toxic software distribution model of ruby and javascript-- it's common for a rust package to have a dependency graph of hundreds of assorted packages, any of which could backdoor your system. It's possible to use rust without using the packaging ecosystem, but doing so is more of a challenge.

Rust and C++ also have no good facilities for formally reasoning about the behaviour of programs (beyond things like the borrow checker in rust).  But C++ is a superset of C and there are tools to rigorously prove things the properties of C code, which means you can write components of C++ programs in C and formally prove things about them.  You could do the same with rust+c but C++ and C share a lot more syntax and behaviour.

In the world of open source Rust and Haskell both have an additional limitation that the community of developers and reviewers for these languages is smaller than that of C++.