19 ms·

I am a volunteer who works on Rust & I do almost all of my open source work in Rust. I am paid as a Ruby web developer. I personally have little interest in sys

I am a volunteer who works on Rust & I do almost all of my open source work in Rust. I am paid as a Ruby web developer. I personally have little interest in systems programming & want Rust to be a productive language for application development. I frequently witness this rush to judge Rust as too complex to be used for business applications based on a few hours of hacking. For this to be a valid judgment, I would think one of two things would need to be true: a) Rust remains this difficult to use once you have experience with it, or b) most business applications are worked on for only a few hours. In my experience, neither of those premises hold. I believe that the rules of Rust not only give you exceptional performance without memory issues (as this article tries to demonstrate), but also that its rules engender a higher degree of correctness and 'well-factoredness' than most languages. I believe Rust is an excellent language for writing applications at every level of the stack when 'craftmanship' matters.

di4na 10y ago
Or ... Business applications do not care about safety.
- shadowmint 10y ago
  It's probably more a case that safety is critically important, but most LOB apps do not have particularly strict performance requirements. ie. java is good enough.
  - kod 10y ago
    Not only is java good enough, it's currently better than rust for networking applications. Hopefully tokio changes that, but it's not 100% there yet.
- tatterdemalion 10y ago
  Please read my comment more carefully. My argument has nothing to do with safety, and flippant replies are quite rude. > I believe that the rules of Rust not only give you exceptional performance without memory issues (as this article tries to demonstrate), but also that its rules engender a higher degree of correctness and 'well-factoredness' than most languages. I believe Rust is an excellent language for writing applications at every level of the stack when 'craftmanship' matters.
  - di4na 10y ago
    And once again, i stay my case in the fact that "higher degree of correctness and well-factoredness" is probably not rewarded at all. Which means that the system do not push people to move to something that make these factors better. Performance is not one either. And i am not saying it is good. I strongly support your case. But the thing is, these factors do not matters for most business out there.
    - tatterdemalion 10y ago
      Fortunately the number of businesses that have to value correctness, craftmanship, safety, or performance over 'moving fast and breaking things' is not that high in order for Rust to succeed. I would agree that it will always be a language in the minority, but I think the industry is moving in an increasingly pluralistic direction as regards programming languages & that (nearly) all languages will be minority languages.
kazagistar 10y ago
I'm compiler error feel like a matter of course, just another part of writing code. Errors the compiler didn't catch (and potentially could have), those annoy me.
bryanrasmussen 10y ago
Well it might be that businesses don't want to invest in anything with a high learning curve if there are tools with a low learning curve that can solve the same problem.
- tatterdemalion 10y ago
  Indeed! I don't believe that there are tools with a lower learning curve that solve the same problem Rust does - in particular my belief is the way that Rust is able to perform deep type analysis on imperative code (which is really what the dreaded borrow checker is all about) enables proficient users to write well-factored systems with a high degree of confidence in their correctness. If you want to onboard people to your code base with no familiarity with the language or your system and have them be 'productive' (for some definition of productive) within the week, Rust is probably not the right choice for you. In my experience projects for which that is a high priority (and the languages which enable them) also deal with a great amount of technical debt.
  - problems 10y ago
    You can definitely use languages that are just as safe, but higher level. You could make that argument with many functional languages like Scala or Clojure, you could even make an argument that even many imperative languages are also that solid - like C# or Java. Perhaps not quite as safe, but at least that they deliver the important parts of that safety without the cost of the learning curve. If you want something more precise - you can use Scala in a way that it's almost an imperative language with additional safety guarantees. The only gain you get going to Rust is really in the performance department. Rust is what you use if you want C-level performance combined with that safety, it might replace C and C++ as the OS, browser, high performance server and game development language. For anything else I find it hard to suggest Rust as a serious option when there are many high level languages that seem like better answers.
    - jmcomets 10y ago
      > Perhaps not quite as safe, but at least that they deliver the important parts of that safety without the cost of the learning curve. Sorry to say this but a lot of unsafe code has been written in Java or C#, putting aside the NPEs and such. In Rust safety isn't only about eliminating SEGFAULTs and buffer overflows, but also preventing data races and most concurrency issues. It's common to add threading to cpu-bound code, without worrying about deadlocks or race conditions. Rust also allows some very high-level code. Some of my favorite options out there: - option (std): https://doc.rust-lang.org/std/option/index.html https://doc.rust-lang.org/std/option/index.html - serde: https://github.com/serde-rs/serde https://github.com/serde-rs/serde - docopt: https://github.com/docopt/docopt.rs https://github.com/docopt/docopt.rs Some more features: generics (traits!), immutability by default, type inference, first-class functions, operator overloading, conversion between related types.
jonathanstrange 10y ago
For me personally Rust is not very interesting because it doesn't have a garbage collector. Manual memory management is just a pain in the ass and really not worth it for the vast majority of applications - games and realtime audio processing are an exception. Besides, if I don't want automatic memory management, I could also use Ada or Freepascal, who are both reasonably safe, though not generally as safe as Rust, and are mature and have a well-established toolchain.
- foepys 10y ago
  I have never done anything with Rust but I was under the impression that Rust's borrowing and ownership system made manually freeing memory more or less obsolete except for a few edge cases where the compiler isn't intelligent enough. Is this impression false?
  - tatterdemalion 10y ago
    You are correct, you essentially never need to manually free memory.
  - adrianN 10y ago
    Manual resource management in Rust is about as convenient as manual resource management in modern C++. That is, you don't really do any "manual" memory management at all in >90% of your code, it's all taken care of by RAII.
    - pjmlp 10y ago
      Yes, but with the added benefit not requiring external tooling to validate those RAII pattern are used correctly and forcing not so security savvy developers to actually use them.
      - kazagistar 10y ago
        So it's better, safer, but still manual memory management.
AsyncAwait 10y ago
I second this. Rust gets miles easier after you internalise the borrow checker, which takes anywhere from a week to several, but it's definitely worth it. I believe part of the reason is that people have limited time to play with this stuff and so they want instant gratification. Rust is not like that, but offers a much higher dose of delayed gratification instead. Once you familiarise yourself with the rules and get things working on the first or second compile, it means not only that you program appears to be working, but that it also passes a complex set of tests verified at compile time. When you become confident enough with Rust, you're basically as productive as with any other compiled language, with the added benefit that the code you wrote might actually be (re)usable afterwards. With Rust, you put in some work up front and reap the benefits since then, with other languages you can feel 'productive' right away, but not be able to write production grade software for weeks/months to come. Once you realise this, spending more than a few hours with Rust becomes an easier calculation.
- k__ 10y ago
  I don't understand what problems the people have with the borrow checker. I can't imagine internalizing the borrow checker is harder than internalizing all the idiosyncratic quirks languages like JavaScript have.
  - dbrgn 10y ago
    The borrow checker prevents code from running at all, sometimes even if the code would be perfectly safe (e.g. two slices to non-overlapping areas of a vector). JavaScript on the other hand is full of quirks, but you get something to work quickly, even if it's buggy. The huge advantage that Rust has over languages like JavaScript is that if it compiles, it's almost guaranteed to run (unless you have logic errors somewhere). I think that fact is greatly under-appreciated.
    - pimeys 10y ago
      > The huge advantage that Rust has over languages like JavaScript is that if it compiles, it's almost guaranteed to run (unless you have logic errors somewhere). I think that fact is greatly under-appreciated. This. In my company, our Rust apps have a very small amount of tests, mostly integration tests written with Python. You need to test certain business logic, but mostly if it compiles, deploy all the things :)
chias 10y ago
I strongly agree with this. Rust has been a pleasure to learn, and I've been using it for everything from small scripts to even some minor web-dev. That said I do think there are areas in which using Rust is legitimately not a great idea. For example, I needed to convert a URL path into a filesystem path, and my code looks like this: let mut basepath = PathBuf::from(path_arg); for component in req.url.path() { basepath.push(percent_decode(component.as_bytes()).decode_utf8_lossy().into_owned()); } Granted -- each part of that makes a lot of sense, and I think it would be to Rust's detriment for things not to be that way. But when my focus has to be on rapid development rather than exacting precision, this sort of verbosity can get in the way. Personally, I have been using Rust anyway because I am trying to shift my development habits away from rapid development and towards exacting precision, and to this end Rust has been a godsend. But I can easily understand why this verbosity may push someone away. I do note, however, that verbosity is not the GP's complaint here.
- tatterdemalion 10y ago
  It seems like you're using the url crate but a different version from what I have docs for (the path() method I see doesn't return an iterator). But I believe that some of those conversions are not optimally necessary. Definitely the into_owned is unnecessary and could be replaced by an & before `percent_decode`. This ownership wrangling is something we'd like to address in the coming year. Then I'm not sure about percent_decode. I think there could be a better convenience for that back and forth casting between utf8 and bytes that's going on. The only real decision you're making here is decode_utf8_lossy vs decode_utf8. I'd like to think this could be encapsulated as two methods on the Url type.
  - chias 10y ago
    Thanks for the critique! This is actually super helpful to me as I try to grow as a Rust developer. The point I'm trying to make though, is that if the developer's focus is on rapid development (which I imagine most people in webdev are), then at the end of the day I just want to urldecode something, and not necessarily worry about the character encodings etc.

di4na 10y ago

Or ... Business applications do not care about safety.

shadowmint 10y ago
It's probably more a case that safety is critically important, but most LOB apps do not have particularly strict performance requirements. ie. java is good enough.
- kod 10y ago
  Not only is java good enough, it's currently better than rust for networking applications. Hopefully tokio changes that, but it's not 100% there yet.
tatterdemalion 10y ago
Please read my comment more carefully. My argument has nothing to do with safety, and flippant replies are quite rude. > I believe that the rules of Rust not only give you exceptional performance without memory issues (as this article tries to demonstrate), but also that its rules engender a higher degree of correctness and 'well-factoredness' than most languages. I believe Rust is an excellent language for writing applications at every level of the stack when 'craftmanship' matters.
- di4na 10y ago
  And once again, i stay my case in the fact that "higher degree of correctness and well-factoredness" is probably not rewarded at all. Which means that the system do not push people to move to something that make these factors better. Performance is not one either. And i am not saying it is good. I strongly support your case. But the thing is, these factors do not matters for most business out there.
  - tatterdemalion 10y ago
    Fortunately the number of businesses that have to value correctness, craftmanship, safety, or performance over 'moving fast and breaking things' is not that high in order for Rust to succeed. I would agree that it will always be a language in the minority, but I think the industry is moving in an increasingly pluralistic direction as regards programming languages & that (nearly) all languages will be minority languages.

kazagistar 10y ago

I'm compiler error feel like a matter of course, just another part of writing code. Errors the compiler didn't catch (and potentially could have), those annoy me.

bryanrasmussen 10y ago

Well it might be that businesses don't want to invest in anything with a high learning curve if there are tools with a low learning curve that can solve the same problem.

tatterdemalion 10y ago
Indeed! I don't believe that there are tools with a lower learning curve that solve the same problem Rust does - in particular my belief is the way that Rust is able to perform deep type analysis on imperative code (which is really what the dreaded borrow checker is all about) enables proficient users to write well-factored systems with a high degree of confidence in their correctness. If you want to onboard people to your code base with no familiarity with the language or your system and have them be 'productive' (for some definition of productive) within the week, Rust is probably not the right choice for you. In my experience projects for which that is a high priority (and the languages which enable them) also deal with a great amount of technical debt.
- problems 10y ago
  You can definitely use languages that are just as safe, but higher level. You could make that argument with many functional languages like Scala or Clojure, you could even make an argument that even many imperative languages are also that solid - like C# or Java. Perhaps not quite as safe, but at least that they deliver the important parts of that safety without the cost of the learning curve. If you want something more precise - you can use Scala in a way that it's almost an imperative language with additional safety guarantees. The only gain you get going to Rust is really in the performance department. Rust is what you use if you want C-level performance combined with that safety, it might replace C and C++ as the OS, browser, high performance server and game development language. For anything else I find it hard to suggest Rust as a serious option when there are many high level languages that seem like better answers.
  - jmcomets 10y ago
    > Perhaps not quite as safe, but at least that they deliver the important parts of that safety without the cost of the learning curve. Sorry to say this but a lot of unsafe code has been written in Java or C#, putting aside the NPEs and such. In Rust safety isn't only about eliminating SEGFAULTs and buffer overflows, but also preventing data races and most concurrency issues. It's common to add threading to cpu-bound code, without worrying about deadlocks or race conditions. Rust also allows some very high-level code. Some of my favorite options out there: - option (std): https://doc.rust-lang.org/std/option/index.html https://doc.rust-lang.org/std/option/index.html - serde: https://github.com/serde-rs/serde https://github.com/serde-rs/serde - docopt: https://github.com/docopt/docopt.rs https://github.com/docopt/docopt.rs Some more features: generics (traits!), immutability by default, type inference, first-class functions, operator overloading, conversion between related types.

jonathanstrange 10y ago

For me personally Rust is not very interesting because it doesn't have a garbage collector. Manual memory management is just a pain in the ass and really not worth it for the vast majority of applications - games and realtime audio processing are an exception. Besides, if I don't want automatic memory management, I could also use Ada or Freepascal, who are both reasonably safe, though not generally as safe as Rust, and are mature and have a well-established toolchain.

foepys 10y ago
I have never done anything with Rust but I was under the impression that Rust's borrowing and ownership system made manually freeing memory more or less obsolete except for a few edge cases where the compiler isn't intelligent enough. Is this impression false?
- tatterdemalion 10y ago
  You are correct, you essentially never need to manually free memory.
- adrianN 10y ago
  Manual resource management in Rust is about as convenient as manual resource management in modern C++. That is, you don't really do any "manual" memory management at all in >90% of your code, it's all taken care of by RAII.
  - pjmlp 10y ago
    Yes, but with the added benefit not requiring external tooling to validate those RAII pattern are used correctly and forcing not so security savvy developers to actually use them.
    - kazagistar 10y ago
      So it's better, safer, but still manual memory management.

AsyncAwait 10y ago

I second this. Rust gets miles easier after you internalise the borrow checker, which takes anywhere from a week to several, but it's definitely worth it. I believe part of the reason is that people have limited time to play with this stuff and so they want instant gratification. Rust is not like that, but offers a much higher dose of delayed gratification instead. Once you familiarise yourself with the rules and get things working on the first or second compile, it means not only that you program appears to be working, but that it also passes a complex set of tests verified at compile time. When you become confident enough with Rust, you're basically as productive as with any other compiled language, with the added benefit that the code you wrote might actually be (re)usable afterwards. With Rust, you put in some work up front and reap the benefits since then, with other languages you can feel 'productive' right away, but not be able to write production grade software for weeks/months to come. Once you realise this, spending more than a few hours with Rust becomes an easier calculation.

k__ 10y ago
I don't understand what problems the people have with the borrow checker. I can't imagine internalizing the borrow checker is harder than internalizing all the idiosyncratic quirks languages like JavaScript have.
- dbrgn 10y ago
  The borrow checker prevents code from running at all, sometimes even if the code would be perfectly safe (e.g. two slices to non-overlapping areas of a vector). JavaScript on the other hand is full of quirks, but you get something to work quickly, even if it's buggy. The huge advantage that Rust has over languages like JavaScript is that if it compiles, it's almost guaranteed to run (unless you have logic errors somewhere). I think that fact is greatly under-appreciated.
  - pimeys 10y ago
    > The huge advantage that Rust has over languages like JavaScript is that if it compiles, it's almost guaranteed to run (unless you have logic errors somewhere). I think that fact is greatly under-appreciated. This. In my company, our Rust apps have a very small amount of tests, mostly integration tests written with Python. You need to test certain business logic, but mostly if it compiles, deploy all the things :)

chias 10y ago

I strongly agree with this. Rust has been a pleasure to learn, and I've been using it for everything from small scripts to even some minor web-dev. That said I do think there are areas in which using Rust is legitimately not a great idea. For example, I needed to convert a URL path into a filesystem path, and my code looks like this: let mut basepath = PathBuf::from(path_arg); for component in req.url.path() { basepath.push(percent_decode(component.as_bytes()).decode_utf8_lossy().into_owned()); } Granted -- each part of that makes a lot of sense, and I think it would be to Rust's detriment for things not to be that way. But when my focus has to be on rapid development rather than exacting precision, this sort of verbosity can get in the way. Personally, I have been using Rust anyway because I am trying to shift my development habits away from rapid development and towards exacting precision, and to this end Rust has been a godsend. But I can easily understand why this verbosity may push someone away. I do note, however, that verbosity is not the GP's complaint here.

tatterdemalion 10y ago
It seems like you're using the url crate but a different version from what I have docs for (the path() method I see doesn't return an iterator). But I believe that some of those conversions are not optimally necessary. Definitely the into_owned is unnecessary and could be replaced by an & before `percent_decode`. This ownership wrangling is something we'd like to address in the coming year. Then I'm not sure about percent_decode. I think there could be a better convenience for that back and forth casting between utf8 and bytes that's going on. The only real decision you're making here is decode_utf8_lossy vs decode_utf8. I'd like to think this could be encapsulated as two methods on the Url type.
- chias 10y ago
  Thanks for the critique! This is actually super helpful to me as I try to grow as a Rust developer. The point I'm trying to make though, is that if the developer's focus is on rapid development (which I imagine most people in webdev are), then at the end of the day I just want to urldecode something, and not necessarily worry about the character encodings etc.