4 ms·

It's because Rust's fundamental concerns—ownership, error handling, mutability, etc.—are at a much lower level than most applications need to deal with. Rust h

It's because Rust's fundamental concerns—ownership, error handling, mutability, etc.—are at a much lower level than most applications need to deal with. Rust has the (imo unrealistic) goal of trying to fit an incredibly broad range of use-cases, from embedded microcontrollers to command-line tools to web frameworks, each of which has a different level of abstraction and concerns that are important. When you go up the ladder of abstraction like in this project, stack vs heap, ownership, et al get in the way of dealing with application logic.

brundolf 5y ago
The thing though is you can build higher-level abstractions on top of the base language (and Rust’s type system helps keep these abstractions from getting shaky). Macros also help a lot with eliminating ceremony, as demonstrated really well by Rocket. I agree it’s stretching for a wide swath of cases, and it will be interesting to see how much of that space it ends up becoming popular for, but I’m not sure I’d call it “unrealistic”. Part of the problem right now - especially in the web space - isn’t the language but a lack of time investment in the ecosystem. Rocket is the most promising web framework Rust has, and its current release has been in RC for 6 months (!). I really hope it gets corporate backing at some point.
- nauticacom 5y ago
  > The thing though is you can build higher-level abstractions on top of the base language That's true, but since the base language is so low-level there are certain things you can't get away from. You can never get away from the fact that String/&str and Vec/&[] are different. If I'm writing code where every allocation counts, then I need a language to be able to, for example, give me a substring without allocating. If I'm writing web code, though, the number of allocations is probably in the thousands or tens of thousands and I just don't care. But using Rust, I have to care about the difference between allocated types and slices, which is unnecessary complexity. You can never get away from the fact that heap allocations are explicit, so most kinds of dynamism, since they rely on runtime polymorphism, need to go through Boxes or generic types or something else. I can't count the number of time's I've needed to Box something because I needed runtime polymorphism, or needed to rework an interface because I had Boxed something but now it's not object-safe. You can never get away from Rust's ownership model, which wreaks havoc on graph-like structures that are common in a domain model (which you'll undoubtedly have in your web app/api. It's no big deal for a language with a GC, but because the memory semantics are difficult, Rust forces that difficulty onto you. Again, it would make sense if I only had some tiny amount of RAM to work with on a microcontroller, but I can spare gigs of server RAM. All of these (and others, these are just examples) add up to complexity that is unnecessary and overwhelming for the level of abstraction that web projects deal with. Rust certainly has many great things, but it's a trade off, and imo it's one that's not worth it. Personally, I think tools are better when they target a specific audience with specific goals and specific use-cases. I suppose I stretched calling it "unrealistic" for Rust, since, well, look where it is; I guess it's more just a position I don't understand or agree with. Honestly the best part of Rust is (most of) the community. Most of the people I interact with are incredibly friendly, welcoming, and interested in making the community better. I wish Swift had half the community Rust does, and wasn't so Apple-controlled, because it feels like an applications-friendly version of Rust.
  - brundolf 5y ago
    Several of the roadblocks you mention can be worked-around using things like Rc, RefCell, and Cow. By default these will still make things more verbose than languages that are GCed, but they free up your overall architecture to do things the way you'd expect to do them in those other languages. And these are just the standard-lib baseline: with macros, traits, and careful use of unsafe {} inside your own abstractions, you can make more things implicit and ergonomic than the base language allows by default. Rust is definitely not yet as ergonomic as something like Node for writing web servers. Even if Rocket were 100% production-ready, I probably wouldn't recommend it over a GCd language in my own organization unless we needed a) crazy performance or b) crazy type-safety. But could Rust get there one day? > I suppose I stretched calling it "unrealistic" for Rust, since, well, look where it is; I guess it's more just a position I don't understand or agree with I would call Rust's attempted breadth ambitious. I think it's charting new territory and I'm very curious to see how far it will be able to stretch. I don't know the outcome here; nobody does. It's very possible it will never take off for mainstream web dev and will be confined to systems, tooling, etc. But I think there's potential, and I think it's too early to call.

brundolf 5y ago

The thing though is you can build higher-level abstractions on top of the base language (and Rust’s type system helps keep these abstractions from getting shaky). Macros also help a lot with eliminating ceremony, as demonstrated really well by Rocket. I agree it’s stretching for a wide swath of cases, and it will be interesting to see how much of that space it ends up becoming popular for, but I’m not sure I’d call it “unrealistic”. Part of the problem right now - especially in the web space - isn’t the language but a lack of time investment in the ecosystem. Rocket is the most promising web framework Rust has, and its current release has been in RC for 6 months (!). I really hope it gets corporate backing at some point.

nauticacom 5y ago
> The thing though is you can build higher-level abstractions on top of the base language That's true, but since the base language is so low-level there are certain things you can't get away from. You can never get away from the fact that String/&str and Vec/&[] are different. If I'm writing code where every allocation counts, then I need a language to be able to, for example, give me a substring without allocating. If I'm writing web code, though, the number of allocations is probably in the thousands or tens of thousands and I just don't care. But using Rust, I have to care about the difference between allocated types and slices, which is unnecessary complexity. You can never get away from the fact that heap allocations are explicit, so most kinds of dynamism, since they rely on runtime polymorphism, need to go through Boxes or generic types or something else. I can't count the number of time's I've needed to Box something because I needed runtime polymorphism, or needed to rework an interface because I had Boxed something but now it's not object-safe. You can never get away from Rust's ownership model, which wreaks havoc on graph-like structures that are common in a domain model (which you'll undoubtedly have in your web app/api. It's no big deal for a language with a GC, but because the memory semantics are difficult, Rust forces that difficulty onto you. Again, it would make sense if I only had some tiny amount of RAM to work with on a microcontroller, but I can spare gigs of server RAM. All of these (and others, these are just examples) add up to complexity that is unnecessary and overwhelming for the level of abstraction that web projects deal with. Rust certainly has many great things, but it's a trade off, and imo it's one that's not worth it. Personally, I think tools are better when they target a specific audience with specific goals and specific use-cases. I suppose I stretched calling it "unrealistic" for Rust, since, well, look where it is; I guess it's more just a position I don't understand or agree with. Honestly the best part of Rust is (most of) the community. Most of the people I interact with are incredibly friendly, welcoming, and interested in making the community better. I wish Swift had half the community Rust does, and wasn't so Apple-controlled, because it feels like an applications-friendly version of Rust.
- brundolf 5y ago
  Several of the roadblocks you mention can be worked-around using things like Rc, RefCell, and Cow. By default these will still make things more verbose than languages that are GCed, but they free up your overall architecture to do things the way you'd expect to do them in those other languages. And these are just the standard-lib baseline: with macros, traits, and careful use of unsafe {} inside your own abstractions, you can make more things implicit and ergonomic than the base language allows by default. Rust is definitely not yet as ergonomic as something like Node for writing web servers. Even if Rocket were 100% production-ready, I probably wouldn't recommend it over a GCd language in my own organization unless we needed a) crazy performance or b) crazy type-safety. But could Rust get there one day? > I suppose I stretched calling it "unrealistic" for Rust, since, well, look where it is; I guess it's more just a position I don't understand or agree with I would call Rust's attempted breadth ambitious. I think it's charting new territory and I'm very curious to see how far it will be able to stretch. I don't know the outcome here; nobody does. It's very possible it will never take off for mainstream web dev and will be confined to systems, tooling, etc. But I think there's potential, and I think it's too early to call.