5 ms·

> 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 ther

> 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.

agentgt 10y ago
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 https://youtu.be/pTQxHIzGqFI?t=964A [2]: https://github.com/Antti/rust-amqp https://github.com/Antti/rust-amqp
- ngrilly 10y ago
  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.
kornholi 10y ago
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.
- tmzt 10y ago
  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.
fiedzia 10y ago
> 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.
twic 10y ago
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.
schoenobates 10y ago
I'm not a RUST chap, but came across this the other day: http://www.arewewebyet.org/ 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.
- tmzt 10y ago
  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.
  - steveklabnik 10y ago
    Dot org is the takeover of the old dot com, which is what you were thinking of.
    - tmzt 10y ago
      Okay, there was an attempt made to get the .com redirected?
      - steveklabnik 10y ago
        It currently does.
        tmzt 10y ago
        Okay, sorry for the confusion.
        steveklabnik 10y ago
        It's all good! It was wrong for a very long time. This is a recent development.

agentgt 10y ago

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 https://youtu.be/pTQxHIzGqFI?t=964A [2]: https://github.com/Antti/rust-amqp https://github.com/Antti/rust-amqp

ngrilly 10y ago
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.

kornholi 10y ago

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.

tmzt 10y ago
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.

fiedzia 10y ago

> 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.

twic 10y ago

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.

schoenobates 10y ago

I'm not a RUST chap, but came across this the other day: http://www.arewewebyet.org/ 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.

tmzt 10y ago
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.
- steveklabnik 10y ago
  Dot org is the takeover of the old dot com, which is what you were thinking of.
  - tmzt 10y ago
    Okay, there was an attempt made to get the .com redirected?
    - steveklabnik 10y ago
      It currently does.
      - tmzt 10y ago
        Okay, sorry for the confusion.
        steveklabnik 10y ago
        It's all good! It was wrong for a very long time. This is a recent development.