5 ms·

In my opinion, the section which the author called "the ugly" makes it clear that it's not that surprisingly good as a application server language. A file uplo

In my opinion, the section which the author called "the ugly" makes it clear that it's not that surprisingly good as a application server language. A file upload is a basic feature that has already been solved yet Rust code contains a lot of boilerplate when compared with Python. Remember the mantra from the 2010's when the dynamic typing craze? Rust is not about optimizing developer time, it's about guaranteeing safety for base sysstems software. All this permanent reasoning about ownership, borrowing and so on makes it the greatest contender against C++ (hence Mozilla and Microsoft support) but in terms of productivity you'd be best served with a higher level, GC-collected platform for an application.

sanxiyn 6y ago
The point of the article is that lack of good support for file upload IS a productivity hit, but ownership reasoning IS NOT a productivity hit. And file upload can be solved by just more code. This indeed matches my experience.
- zozbot234 6y ago
  > And file upload can be solved by just more code. Yes, but it's a papercut. How many other papercuts are there, compared to more developed ecosystems for this domain? That's not an easy question to address.
  - pantulis 6y ago
    Or take the ORM as an example. Doesn't even begin to compare with 2012's ActiveRecord from Rails land. Not to be surprised, as Rails used a lot of dynamic magic that is simply not doable in Rust. Granted, it's more than enough for a lot of use cases but it wouldn't seem to me like the most appropriate approach for, say, and e-commerce platform in terms of maintainability and time to market. Of course, the performance speedup would be huge on the other hand.
    - monadic2 6y ago
      Conversely, active record can’t generate the SQL you can learn in a few minutes in a database class. I’d much rather have highly precise sql serialization and deserialization code and emphasis on minimal client overhead in a systems language than the ability to rapidly spike a data model and query it in the space of a PowerPoint slide.
      - pantulis 6y ago
        Sure, as with any ORM. But then you have also stated the point: systems language, which is the perfect use case for Rust. The original article talks about a "server language", as in application server, and my whole point was that for building business applications this is a weakness, not a strength.
        monadic2 6y ago
        I don’t see what excludes building an application server with a systems programming language. Business applications have maintenance costs that the ORM backloads; it’s not like all businesses need to do this. There’s nothing inherently “business logic friendly” about an ORM.
- pantulis 6y ago
  Yes, that was my point, not the article. Honest question: how many hours would you say it took you to grok the ownership/borrowing stuff and then reason about it in a natural way so you were as productive as with the language you were coming from?
  - sanxiyn 6y ago
    I didn't measure in terms of hours, but it certainly didn't take more than a month for me. Also for others I taught.
- joppy 6y ago
  Ownership reasoning is not a productivity history in a web server, where the lifetime of pretty much everything is a single request which is handled and then disposed of. This is pretty much the simplest case for ownership. In a different application (say, one running a GUI with many objects which live for indeterminate amounts of time and can be shared across views), ownership reasoning can be extremely complicated. I’m not saying having to reason about ownership is bad, I’m just saying that this is not a good test for whether ownership reasoning is difficult or not.
  - zozbot234 6y ago
    The thing with ownership reasoning in Rust is that you can opt out of it whenever it makes sense to do so. If you really have "objects which live for indeterminate amounts of time and can be shared across views", that's not an increase in complexity; you just acknowledge that reasoning about ownership and sharing at compile time is not going to be feasible, write Rc<RefCell<…>> (with a documentation comment to that effect) and move on. All it takes is knowing where to add a tiny bit of boilerplate.
    - amelius 6y ago
      Yes, but you still can't write garbage collected code, which is tremendously useful in many circumstances. E.g. when using closures you really don't want to be thinking about memory allocation, and closures have proven a very useful concept. There are countless of reasons why the availability of a GC is a productivity booster. So I wouldn't describe Rust as a language that fits all domains and/or programmers well.
      - pasabagi 6y ago
        Isn't Rc<T> essentially garbage collection though?
        amelius 6y ago
        Reference counting is a form of garbage collection, but with closures you often end up with circular dependencies, which is what RC can't handle.

sanxiyn 6y ago

The point of the article is that lack of good support for file upload IS a productivity hit, but ownership reasoning IS NOT a productivity hit. And file upload can be solved by just more code. This indeed matches my experience.

zozbot234 6y ago
> And file upload can be solved by just more code. Yes, but it's a papercut. How many other papercuts are there, compared to more developed ecosystems for this domain? That's not an easy question to address.
- pantulis 6y ago
  Or take the ORM as an example. Doesn't even begin to compare with 2012's ActiveRecord from Rails land. Not to be surprised, as Rails used a lot of dynamic magic that is simply not doable in Rust. Granted, it's more than enough for a lot of use cases but it wouldn't seem to me like the most appropriate approach for, say, and e-commerce platform in terms of maintainability and time to market. Of course, the performance speedup would be huge on the other hand.
  - monadic2 6y ago
    Conversely, active record can’t generate the SQL you can learn in a few minutes in a database class. I’d much rather have highly precise sql serialization and deserialization code and emphasis on minimal client overhead in a systems language than the ability to rapidly spike a data model and query it in the space of a PowerPoint slide.
    - pantulis 6y ago
      Sure, as with any ORM. But then you have also stated the point: systems language, which is the perfect use case for Rust. The original article talks about a "server language", as in application server, and my whole point was that for building business applications this is a weakness, not a strength.
      - monadic2 6y ago
        I don’t see what excludes building an application server with a systems programming language. Business applications have maintenance costs that the ORM backloads; it’s not like all businesses need to do this. There’s nothing inherently “business logic friendly” about an ORM.
pantulis 6y ago
Yes, that was my point, not the article. Honest question: how many hours would you say it took you to grok the ownership/borrowing stuff and then reason about it in a natural way so you were as productive as with the language you were coming from?
- sanxiyn 6y ago
  I didn't measure in terms of hours, but it certainly didn't take more than a month for me. Also for others I taught.
joppy 6y ago
Ownership reasoning is not a productivity history in a web server, where the lifetime of pretty much everything is a single request which is handled and then disposed of. This is pretty much the simplest case for ownership. In a different application (say, one running a GUI with many objects which live for indeterminate amounts of time and can be shared across views), ownership reasoning can be extremely complicated. I’m not saying having to reason about ownership is bad, I’m just saying that this is not a good test for whether ownership reasoning is difficult or not.
- zozbot234 6y ago
  The thing with ownership reasoning in Rust is that you can opt out of it whenever it makes sense to do so. If you really have "objects which live for indeterminate amounts of time and can be shared across views", that's not an increase in complexity; you just acknowledge that reasoning about ownership and sharing at compile time is not going to be feasible, write Rc<RefCell<…>> (with a documentation comment to that effect) and move on. All it takes is knowing where to add a tiny bit of boilerplate.
  - amelius 6y ago
    Yes, but you still can't write garbage collected code, which is tremendously useful in many circumstances. E.g. when using closures you really don't want to be thinking about memory allocation, and closures have proven a very useful concept. There are countless of reasons why the availability of a GC is a productivity booster. So I wouldn't describe Rust as a language that fits all domains and/or programmers well.
    - pasabagi 6y ago
      Isn't Rc<T> essentially garbage collection though?
      - amelius 6y ago
        Reference counting is a form of garbage collection, but with closures you often end up with circular dependencies, which is what RC can't handle.