4 ms·

I don't really see why it would be odd, other than the ecosystem not having quite caught up yet with some other languages. It's an expressive, high level langua

by lambda 11y ago

I don't really see why it would be odd, other than the ecosystem not having quite caught up yet with some other languages. It's an expressive, high level language, which makes being explicit about error handling very easy, the type system makes it a lot easier to guarantee at compile time that a number of errors possible in dynamic languages will never happen, and it's quite efficient. The efficiency and explicit memory ownership in Rust makes it a lot easier to avoid some of the scalability problems you run into in dynamic languages. The amount of material you can find online on people discussing hunting down memory leaks in Rails, or discussing how they just scale up by throwing gobs of RAM and extra servers at the problem or restarting their app every day or two, is all stuff that is much easier to avoid in a language like Rust. It is possible to leak memory in Rust, but due to how explicit you are about how memory is owned, it's less likely and more likely to be easier to track down if you do. It is a bit more conceptual overhead to learn Rust than many dynamic languages, but I think that overhead is well spent as it can pay off in performance, stability, and maintainability later on.

nickjj 11y ago
It's unfortunate that the ecosystem is such a strong point for so many people. Sure I might need 250mb of RAM for a Rails app but there's 10+ years of real life thought and care put into the framework and about the same in external gems/blog posts/etc.. I'm ok with spending $5/month on an instance to serve a Rails app for 95% of use cases and I'm a load balancer away from multiplying my throughput if I need to scale out. If I could snap my fingers and have the same ecosystem in Rust I would switch instantly but it's not the world we live in. I'm not sure if even 5 years will be enough because Go 1.0 has been out almost 4 years and it's still not even in the same galaxy as Rails in terms of ecosystem.
- lambda 11y ago
  Of course, now that increasingly more work is being done on the client side, or by communicating with microservices, Rust makes more sense for a pure API backend. There's a lot less ecosystem needed there; mostly just bindings to whatever database you need to talk to, possibly some other stuff. So if you're just going to be exposing a RESTful API backend for a JavaScript based frontend, or even for a Rails app frontend to talk to, Rust makes a lot more sense. Also, the only way an ecosystem gets bootstrapped up is by people scratching their own itches. By starting to write web services in Rust now, and implementing those things that aren't yet implemented, you can help to bootstrap it up. Of course, that only works if you have the extra time to spare to do so, but for those things that only need one or two extra things that don't yet exist, it may pay off due to the lower chances of having to debug runtime errors, less time and complexity spent trying to make it scale out, etc.
  - nickjj 11y ago
    I would still prefer to use ActiveRecord and a whole lot of other pieces of Rails for an app that's purely an API backend. Ex: http://edgeguides.rubyonrails.org/api_app.html http://edgeguides.rubyonrails.org/api_app.html On the Python side of things, I'd use tools like SQLAlchemy and a few other packages. Every web application I've built can still be efficiently modeled with a relational database. An ORM that lets me model things quickly and allows me to avoid shooting myself in the foot by easily monitoring raw queries is going to win in my book when it comes to picking a tech stack to work with. The major ecosystem problem is that no one can just wake up and be like... I'm going to spend the next year making a Rust version of Rails. These features and ideas need to come from real life use cases, that's really 99% of Rails' success. It can be done in any language of course, but you're 10 years behind the curve.
    - steveklabnik 11y ago
      The current maintainer of ActiveRecord is writing an ORM in Rust: diesel. It's not a port, but still, you might be interested in checking it out.
      - nickjj 11y ago
        Definitely interested on keeping tabs on it. Thanks for the heads up. In a perfect world, it wouldn't be a port, but something that meshes really well with real world use cases while taking advantage of what Rust has to offer. I don't mind change (I embrace it), but it needs to be for a REALLY good reason.

by lambda 11y ago

nickjj 11y ago

It's unfortunate that the ecosystem is such a strong point for so many people. Sure I might need 250mb of RAM for a Rails app but there's 10+ years of real life thought and care put into the framework and about the same in external gems/blog posts/etc.. I'm ok with spending $5/month on an instance to serve a Rails app for 95% of use cases and I'm a load balancer away from multiplying my throughput if I need to scale out. If I could snap my fingers and have the same ecosystem in Rust I would switch instantly but it's not the world we live in. I'm not sure if even 5 years will be enough because Go 1.0 has been out almost 4 years and it's still not even in the same galaxy as Rails in terms of ecosystem.

lambda 11y ago
Of course, now that increasingly more work is being done on the client side, or by communicating with microservices, Rust makes more sense for a pure API backend. There's a lot less ecosystem needed there; mostly just bindings to whatever database you need to talk to, possibly some other stuff. So if you're just going to be exposing a RESTful API backend for a JavaScript based frontend, or even for a Rails app frontend to talk to, Rust makes a lot more sense. Also, the only way an ecosystem gets bootstrapped up is by people scratching their own itches. By starting to write web services in Rust now, and implementing those things that aren't yet implemented, you can help to bootstrap it up. Of course, that only works if you have the extra time to spare to do so, but for those things that only need one or two extra things that don't yet exist, it may pay off due to the lower chances of having to debug runtime errors, less time and complexity spent trying to make it scale out, etc.
- nickjj 11y ago
  I would still prefer to use ActiveRecord and a whole lot of other pieces of Rails for an app that's purely an API backend. Ex: http://edgeguides.rubyonrails.org/api_app.html http://edgeguides.rubyonrails.org/api_app.html On the Python side of things, I'd use tools like SQLAlchemy and a few other packages. Every web application I've built can still be efficiently modeled with a relational database. An ORM that lets me model things quickly and allows me to avoid shooting myself in the foot by easily monitoring raw queries is going to win in my book when it comes to picking a tech stack to work with. The major ecosystem problem is that no one can just wake up and be like... I'm going to spend the next year making a Rust version of Rails. These features and ideas need to come from real life use cases, that's really 99% of Rails' success. It can be done in any language of course, but you're 10 years behind the curve.
  - steveklabnik 11y ago
    The current maintainer of ActiveRecord is writing an ORM in Rust: diesel. It's not a port, but still, you might be interested in checking it out.
    - nickjj 11y ago
      Definitely interested on keeping tabs on it. Thanks for the heads up. In a perfect world, it wouldn't be a port, but something that meshes really well with real world use cases while taking advantage of what Rust has to offer. I don't mind change (I embrace it), but it needs to be for a REALLY good reason.