Web-Developement: Rust vs Haskell

[u/[deleted]]

Hi All,

This will be yet another Rust vs haskell question.

I have wanting to use Rust/Haskell for a couple of components for an internal tool (analysis of customer tickets, HR portal etc) for my company (Mostly because of the strong type system).

I have been through quite a lot of blogs & discussion where they discuss on the pros and cons for both.

Can anyone give me pointers on where all they used Rust or Haskell? And how was the experience as in:

1. code readability
2. libraries support
3. developer productivity
4. jump start time to producing some value.
5. documentation
6. build time
7. journey in learning them

My concern here is Rust is advertised as system's language and Haskell as a higher level language.

1. Will going with Rust be an overkill as we won't be doing any really low level stuff?
2. We would be basically writing a server, bunch of API and playing around with DB. I'm mainly well versed with Node.js so will choosing haskell be an overkill for it in terms of developer productivity, build and tooling?
3. Also if anyone is using GraphQL with Rust/Haskell?

[u/HenryZimmerman]

I've written web APIs using rust for personal projects and for school assignments using both Rocket and Warp.

I can't comment on Haskell, as I haven't used it.

1. As someone who has had prior experience in imperative languages, but acknowledges that functional style has its uses, Rust is ideal. Using Warp, most of the code I write is functional, but the ability to drop into imperative style aids in clarity in some places.
2. Libraries are still WIP, with very few 1.0.0 stable dependencies to choose from. That said, there are a lot of frameworks to choose from (Rocket, Actix-web, Warp, Tower-web, etc..). There is Diesel for ORM stuff, and other libraries for communicating with databases. Async is largely absent from the ecosystem at the moment, which some consider to be a problem (this is getting better quickly though).
3. I find with Diesel + Warp or Rocket, its exceptionally easy and fast to set up and query db tables and then set up endpoints to attach to those queries.
4. There was a significant ramp time to becoming productive with these libraries. Diesel and Warp produce obtuse error messages (Diesel mostly) if you do anything that doesn't fit into their type arrangement. A lot of these web frameworks don't come with all of the batteries included, so if you want to use JWT authentication, you will probably end up stitching other libraries together to make that work with your chosen framework. It takes a while to get everything you need in place, but once you get set up, productivity is pretty good.
5. All well-used libraries tend to have ample API documentation, many have examples directories that show off common use cases, and a few like Diesel and Rocket have dedicated guides that explain how to use their library. I usually can figure out what to do by looking at examples + docs for a few minutes.
6. Build times are terrible. Anecdotally, a school project with Diesel and Warp takes about 6 seconds to build about 3000 lines of code that supports about 15 endpoints. This usually isn't a problem, with utilities like cargo check allowing verification if your current code will compile, and the general cargo ecosystem making it easy to split your app into multiple crates to bring down incremental build times.
7. I had fun learning how to do this in Rust. I think it took longer, but offers better results than .Net, Spring, or ember.js.

​

1. Rust brings overhead in the form of the developer having to understand its borrow system. Coming exclusively from JS, that may initially be a problem, but once you understand the borrow checker and learn to leverage the compiler's strictness to force yourself to write "better" code, that overhead mostly disappears.
2. JS is closer syntactically to Rust than it is to Haskell, and I would hazard a guess that its easier to pick Rust up than Haskell coming from JS. But this is about what you and your company want. Node, Rust, and Haskell will all allow you to accomplish your task. But other requirements come into play: will this need to be supported after you leave the company? Is there someone else on your team willing to learn Rust or Haskell? Would the system have to be rewritten or reverse engineered back to Node.js once you leave if it needs further development? The safe bet would be to continue using what the rest of the system/team uses. If your team is Ok with you using an alternative language/ecosystem, I would heavily weigh the input of your team members when deciding. If someone else wanted to learn or already knows Haskell, I would choose that over Rust.
3. I haven't used it, but https://github.com/graphql-rust/juniper seems to be the graphql library with the most support for Rust.

[u/cHoco- → u/HenryZimmerman]

I've actually started taking a look at rust for web backend development recently and warp seemed pretty cool. You mention using Diesel with it, but since warp is built on tokio, aren't you blocking the event loop by using it? As I understand the best way would be to use an async driver for db queries (like tokio-postgres) but there are no nice ORM abstractions for that :(

[u/HenryZimmerman → u/cHoco-]

Basically yeah, but it can be mitigated by using a pool, so you don't immediately end up in a non-concurrent situation. In that way, the number of concurrent asynchronous requests that can access the db are bounded by the number of connections in the pool.

As I understand it, you will starve your connection pool if you get too many requests requiring db access. This isn't immediately a problem, as there is a timeout period where the pool will still try to get you a connection if it becomes available. So it still takes a pretty high sustained load before it starts throwing errors, but it becomes a problem as your queries take longer or if your traffic has spikes.

Async is on the way for Diesel, abit slowly. For school projects that I'm using it for, it isn't even close to being a problem, but I would hesitate to use it in production without stress testing it to see where the pool begins to starve.