8 ms·

This is all personal opinion so take it with a grain of salt. I think Rust could do some serious C++ competition if it could dethrone C++ from some platform or

by agentgt 10y ago

This is all personal opinion so take it with a grain of salt. I think Rust could do some serious C++ competition if it could dethrone C++ from some platform or have a worthy alternative. That is I think Rust really needs a killer app/platform/problem similar to how Swift has Apple devices and DevOps now have Go. If Rust could get into a gaming platform or have a really good gaming library like Unity it could have a good starting point to move over mind share. 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). Rust's current niche (ie users) is language aficionados which historically hasn't been a good niche (ie Haskell) for language propagation. That is I think Rust could get more popular if it can get heavily used by a set of niche users at first. Besides mircoservices and games an interesting niche might be Arduino and IOT [1]. That might be a good niche/platform to dethrone C++. [1]: http://jakegoulding.com/blog/2016/01/02/rust-on-an-arduino-uno/ http://jakegoulding.com/blog/2016/01/02/rust-on-an-arduino-u...

bluejekyll 10y ago
For those not aware of it, Tokio https://github.com/tokio-rs/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.
- mastax 10y ago
  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.
mi100hael 10y ago
> 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.
setori88 10y ago
Regarding microservices; it's my hopes https://github.com/fractalide/fractalide https://github.com/fractalide/fractalide moves into this space.

by agentgt 10y ago

bluejekyll 10y ago

For those not aware of it, Tokio https://github.com/tokio-rs/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.

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

mi100hael 10y ago

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

setori88 10y ago

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