5 ms·

If your primary goal is productivity, I don't think rust will ever be the right language for you. If you want to remain relatively productive while building th

by jamwt 10y ago

If your primary goal is productivity, I don't think rust will ever be the right language for you. If you want to remain relatively productive while building things that are one or more of (large, fast, safe), it's an excellent choice.

gcp 10y ago
I'm not sure. I'm tempted to say I'm about as productive (in orders of magnitude) in any language that I'm very familiar with and has a large enough "batteries included" component (yes, crates would count, as does npm). Even C++ as long as the extras from boost are there. I can type reasonably correct code much faster than I can reason about how the program should work.
- jamwt 10y ago
  I'm not saying unproductive. I'm saying, we need to be realistic. Compared to, say, Python, it's nowhere close. Compared to C++, Java, or even Go, it's anywhere from competitive to significantly better.
  - flukus 10y ago
    You may be using a different definition of productive. I wouldn't consider python or any dynamic language productive on a large project.
vertex-four 10y ago
Add maintainable to that list. A program where its developers have a fuzzy idea of ownership of data is not in any way maintainable.
- jamwt 10y ago
  Yep, that's what I meant about "large". If you have a large project, with many developers you're going to want types + generics to maintain it over the many-years and 100,000s to millions of SLOC life.
  - JoelMcCracken 10y ago
    Rust is hardly the only language to have a type system that supports generics.
    - jamwt 10y ago
      I didn't say it was! I said it was an "excellent choice". Right?
      - JoelMcCracken 10y ago
        Right. But, what I'm saying is, generics does not make Rust unique. There are many other good languages that I think may be a better choice.
- JoelMcCracken 10y ago
  This is one of those things that seem plausible, but I have no idea if its really true. I'm not disagreeing, I just can't see it as being obviously true. Can you give me an example of how a fuzzy idea of ownership causes, ideally, a real problem, or a less ideally a simplified example problem? I'm 100% genuinely interested in this.
  - isaacaggrey 10y ago
    I can't speak to personal experience since I've only dabbled in Rust, but I have followed it for quite a while and lately I have read more and more how how Rust forces you to structure your data and program in such a way that is more maintainable.
  - vertex-four 10y ago
    It's pretty much the reason for segfaults and use-after-free issues (which manifest as either memory corruption or security vulns) in reasonably sized codebases - without a good understanding of ownership, it's non-obvious when a pointer is supposed to become invalid, and if that doesn't match up with when the data is actually freed, you have an issue that's hard to track down later. If you're using a language with garbage collection, it's obviously not going to result in segfaults, but you can still run into logic errors when part of your code assumes that it's done dealing with a piece of data and another part has a different idea. More generally, if your object is stored in multiple places in your code, you have to remember to clean up all references to it properly, in all the different states your system can be in, and your compiler can't verify you're doing that correctly without a borrow checker.
    - JoelMcCracken 10y ago
      Problems involving memory deallocation in the GC applications I've written seem to happen infrequently, certainly infrequently enough that it is one of the lowest items on my list of things I'd like to fix that cause problems in development. > but you can still run into logic errors when part of your code assumes that it's done dealing with a piece of data and another part has a different idea. Mostly I think this is sufficiently handled by not mutating shared state as a practice. However, since Rust has mutable borrows, it seems to me that you're still in danger of running into this.

by jamwt 10y ago

gcp 10y ago

I'm not sure. I'm tempted to say I'm about as productive (in orders of magnitude) in any language that I'm very familiar with and has a large enough "batteries included" component (yes, crates would count, as does npm). Even C++ as long as the extras from boost are there. I can type reasonably correct code much faster than I can reason about how the program should work.

jamwt 10y ago
I'm not saying unproductive. I'm saying, we need to be realistic. Compared to, say, Python, it's nowhere close. Compared to C++, Java, or even Go, it's anywhere from competitive to significantly better.
- flukus 10y ago
  You may be using a different definition of productive. I wouldn't consider python or any dynamic language productive on a large project.

vertex-four 10y ago

Add maintainable to that list. A program where its developers have a fuzzy idea of ownership of data is not in any way maintainable.

jamwt 10y ago
Yep, that's what I meant about "large". If you have a large project, with many developers you're going to want types + generics to maintain it over the many-years and 100,000s to millions of SLOC life.
- JoelMcCracken 10y ago
  Rust is hardly the only language to have a type system that supports generics.
  - jamwt 10y ago
    I didn't say it was! I said it was an "excellent choice". Right?
    - JoelMcCracken 10y ago
      Right. But, what I'm saying is, generics does not make Rust unique. There are many other good languages that I think may be a better choice.
JoelMcCracken 10y ago
This is one of those things that seem plausible, but I have no idea if its really true. I'm not disagreeing, I just can't see it as being obviously true. Can you give me an example of how a fuzzy idea of ownership causes, ideally, a real problem, or a less ideally a simplified example problem? I'm 100% genuinely interested in this.
- isaacaggrey 10y ago
  I can't speak to personal experience since I've only dabbled in Rust, but I have followed it for quite a while and lately I have read more and more how how Rust forces you to structure your data and program in such a way that is more maintainable.
- vertex-four 10y ago
  It's pretty much the reason for segfaults and use-after-free issues (which manifest as either memory corruption or security vulns) in reasonably sized codebases - without a good understanding of ownership, it's non-obvious when a pointer is supposed to become invalid, and if that doesn't match up with when the data is actually freed, you have an issue that's hard to track down later. If you're using a language with garbage collection, it's obviously not going to result in segfaults, but you can still run into logic errors when part of your code assumes that it's done dealing with a piece of data and another part has a different idea. More generally, if your object is stored in multiple places in your code, you have to remember to clean up all references to it properly, in all the different states your system can be in, and your compiler can't verify you're doing that correctly without a borrow checker.
  - JoelMcCracken 10y ago
    Problems involving memory deallocation in the GC applications I've written seem to happen infrequently, certainly infrequently enough that it is one of the lowest items on my list of things I'd like to fix that cause problems in development. > but you can still run into logic errors when part of your code assumes that it's done dealing with a piece of data and another part has a different idea. Mostly I think this is sufficiently handled by not mutating shared state as a practice. However, since Rust has mutable borrows, it seems to me that you're still in danger of running into this.