> Alternatively I think Rust could compete heavily with Go since the whole microservices space is still sort of up for grabs (or atleast is so massive that there is plenty of pie to be had).

I think you're wrong about this one. Go has a ton of HTTP libraries that make it dead simple to get a web service up and running with all the features you'd expect like pattern-matching URL routing, database backends, sessions, etc. Building something in Rust would be much more painful.

Surprisingly, it's already not that painful. I recently wrote a tiny JSON service with Iron and Diesel and it wasn't that much longer or complex compared to Go. The biggest headache was figuring out how Diesel works, and it would have been a lot easier using raw queries with something like rust-postgres (which would be the way to go in Go or Node). Once the ecosystem matures a little bit more I don't see why Rust would be a bad choice.

Macros 1.1 should make working with Diesel easier for the programmer, compared to the incompatible compiler plugin APIs.

I think the sweet spot with rust might leveraging metaprogramming, for instance, generating a REST database API from a schema and having the resulting code compile to something faster the most languages like python or ruby, and at least on par with Go, Java, or swift.

There are libraries (I didn't downvote you but I suppose that is why as simple googling shows that) [1].

That being said one would argue if you are going the microservices route you shouldn't need an exceptional amount of routing anyway. You only need to really handle raw HTTP for the most part (also I would not say HTTP is the end all for microservices... I have been using a Rust AMQP library with some success [2]).

Also although Go has green threads it is still debatable if that is the right way or golden way particularly when so many backends like databases (e.g. postgres) can't handle async (tons of connections) anyway. Old school one thread per request libraries in Java like dropwizard can still do fairly well. I think Rust made the right choice with native threads and hopefully some interesting green thread or reactive libraries will come forth soon (or already here ... haven't googled it).

Also I'm just not sure I really buy into Go's channels but that is just a personal opinion at the moment.

[1]: https://youtu.be/pTQxHIzGqFI?t=964A

[2]: https://github.com/Antti/rust-amqp

When you need to handle a lot of concurrent connections (from your clients, not to your database), Go green threads are invaluable (better than OS threads because a goroutine requires only 2 KB; and better than callbacks). They are also very useful to express concurrent algorithms.

I assumed that agentgt meant "up for grabs" in the sense of "not yet dominated by any one language", which is true. Go and Java are both big presences in that space, but neither is dominant. A language with the expressiveness of Java and the memory use of Go could be a strong challenger, and Rust is already better than that.

I'm not a RUST chap, but came across this the other day:

http://www.arewewebyet.org/

I've done most of my web service work in either Java or Go, but I'd like to give Rust a try for comparison at some point.

Rust people may have better insight into this, but it seems like that site is outdated and in need of an update.

Edit: I meant to say that I have heard from many of them that the content of that is outdated and in need of an update. There was talk of the community taking it over but I don't have the latest on that.

Dot org is the takeover of the old dot com, which is what you were thinking of.

Okay, there was an attempt made to get the .com redirected?

It currently does.

Okay, sorry for the confusion.

It's all good! It was wrong for a very long time. This is a recent development.

> Building something in Rust would be much more painful.

Go may have more of those things and it may be easier to find copy-pastable examples for them, but rust has them too, and its not painfull. The things you mentioned are there and are working fine.

For those not aware of it, Tokio https://github.com/tokio-rs/tokio is a platform that is being built on top of Rust Futures for building exactly these types of services.

It's built around futures and mio, so Tokio services are async, and elegant.

I'd say if you want to build web-backend type services in Rust right now, you'd do alright. Hyper, mio, diesel, etc. are all pretty good. I do think (and hope) that things will be much more compelling in a year once tokio and its library ecosystem have matured. Tokio's abstractions seem very compelling.

Regarding microservices; it's my hopes https://github.com/fractalide/fractalide moves into this space.