10 ms·

It's also important to note that Go was designed for programmer productivity and Rust wasn't. GC is incredible productivity boost which is why no recent langua

• burntsushi 10y ago
  Arguably, programmer productivity is one consequence of safety (and productivity isn't necessarily only gained by increased safety either of course!). Are there different productivity levels between Go and Rust? Probably. But to say Rust wasn't "designed for programmer productivity" definitely isn't right from where I'm standing.
  • bluejekyll 10y ago
    Honestly, the more you program in rust, the more you get used to its mannerisms. I don't at this point find that I'm less productive in it than in Go, and with gennerics I'm generally able to reuse code more often meaning that I usually write less code. Similarly in C I lose time on screwing up basic things that I have to debug in testing, whereas in Rust I don't have to even worry about that. I'm actually not buying the productivity argument, after you've learned the language. Claiming that it is less productive when you barely know it isn't fair, it's similar to saying that Italian (as an English speaker) is much more complex and hard to communicate in than English, when you've only studied the language for a month. It does have a steep learning curve, so it's either worth it to you to learn it, or not. But once you know it, I think your overall productivity is higher or the same as other languages, and on top of that you end up with fewer production issues!
    • burntsushi 10y ago
      I'd say my experience matches this. I've written well over 50 KLOC of both Go and Rust in the last few years (I love both), and I don't personally experience a big productivity difference between them. There is one dimension where I feel like Rust makes me more productive though: when writing code that I want to go as fast as possible. I bet there are things that would be more productive in Go, maybe building web applications, but I haven't built any in Rust yet, so it's hard to compare. As a reference point, I feel much more productive in Rust/Go than I do in any unityped language. I suspect the same is true of C, but I've never been a heavy C practitioner. I'll stop here though, because this is all pretty subjective and wishy washy, and it will undoubtedly vary from person to person and be dependent on what kinds of problems you're solving most frequently.
    • shadowmint 10y ago
      Claiming that it is less productive when you barely know it isn't fair... I'm really quite familiar with both go and rust, and I can say straight out that go is more productive than rust. ...but because rust is in any way a worse or less productive language (that remains to be seen), but because it has an immature ecosystem with few high quality crates and virtually no tooling. Go has a lot of very polished tooling (eg. gocode) that is supported in multiple editors, and a variety of high level packages for all kinds of things. Certainly I'm willing to acknowledge that if you're using vim without any plugins to write your code, or if you're evaluating the effectiveness of writing individual functions, it's a much more abstract kind of thing. ...but have you actually bench marked yourself coding a real world project, from scratch, in both, from idea to delivery? I have, and for me rust was an order of magnitude less productive than go. At least. Once the tooling for rust gets up and going we'll be a much better position, but... You're effectively saying that there is zero productivity boost in the extensive go tooling ecosystem (which rust currently doesn't have); that's pretty hard sell...
      • steveklabnik 10y ago
        > You're effectively saying that there is zero productivity boost in the extensive go tooling ecosystem (which rust currently doesn't have); that's pretty hard sell... You could say something like "you're effectively saying that there is zero productivity drain from not having features like generics (which Rust currently does have); that's a pretty hard sell... Tooling matters a lot, and that's why we're investing in it. But "tooling" is not a synonym for "productivity." There's a lot of factors.
        • shadowmint 10y ago
          You'd have a much easier time arguing that go not having a package manager makes you less productive compared to cargo (very true); you're kidding yourself if you think having generics makes up for having to write your own AWS client in terms of productivity. Can you build something more quickly in go right now, than in rust? For many applications, the answer is, right now: Yes. Building (using the tooling that does exist, and the libraries that do exist) make completing a project successfully easier and quicker than in rust. Does that make go 'more productive' than rust? Or is 'productivity' just how effective you are at expressing logic as code? Well, I guess it depends what word games you want to play. My personal experience has been that using rust is great, fun (if verbose) and you can spend 5 or 6 hours writing a nice crate that doesn't do anything meaningful; and when you do have to do something meaningful, its a tonne of work to get it to compile (ugh, c libraries...) and you end up having to write or modify/fix the packages to do many of the things yourself. That is not productive. Perhaps you see a different side to it from where you sit, but I do think #rust suffers from a certain degree of confirmation bias. I think 'productivity' depends on your problem domain. For building actual applications rust simply isnt even in the same space as java, c++, c# or go at this point in terms of 'productivity'.
• dikaiosune 10y ago
  I would offer a counterpoint -- Rust's guarantees and strong typing offer a different kind of productivity to an intermediate or experienced user. One where a compiled program is much more likely to be "correct" than in any other mainstream-esque language I've used. The properties which combine to create this effect make refactoring much less scary, allow easier navigation in large codebases (IMO), and allow for other valuable properties for productivity.
  • cgag 10y ago
    This is why I think there's room for another bigtime language that hits the rust sweet spot of functional-flavored imperative programming with a GC.
    • catnaroek 10y ago
      GC for in-memory data structures, RAII and lifetimes for system resources, ML-style type and module systems. That would be very close to the ideal language IMO.
      • aturon 10y ago
        The key problem: in-memory data structures can embed ownership of system resources.
        • catnaroek 10y ago
          I'd take an approach inspired by Standard ML's eqtypes. In Standard ML: (0) Some types are eqtypes (akin to Rust types that implement the Eq trait, but managed entirely by the language, you can't define custom Eq impls). (1) If a type constructor is an eqtype, then the result of applying it to an eqtype is an eqtype, but the result of applying it to a non-eqtype is a non-eqtype. For example, “list of ints” is an eqtype, but “list of functions” isn't. Similarly, I propose that: (0) Some types are copytypes (akin to Rust types that implement the Copy trait, again, managed entirely by the language). (1) If a type constructor is a copytype, the result of applying it to a copytype is a copytype, but the result of applying it to a non-copytype is a non-copytype. For example, “list of ints” is a copytype, but “list of file objects” isn't. Subtleties: (0) If we have first-class functions, functions must be parameterized over whether they can be called more than once (akin to the distinction between FnOnce and Fn in Rust). (1) When a value goes out of scope, its destructor is called. For copytypes, the destructor is guaranteed to be trivial, and can be optimized away. For “base non-copytypes” (e.g., file objects), the destructor is explicitly implemented by the programmer. For “derived non-copytypes” (e.g., lists of file objects, closures that have captured file objects), the destructor is automatically generated, and it does the obvious thing (destroy all file objects in the list, or captured by the closure).
• jdf 10y ago
  I agree with some of your points, but think this is phrased a bit harsh. FWIW, I write both Go and Rust on a regular basis. Here's where I would agree with you: - Go makes it harder for someone to write overly abstract code (a common affliction!). - Being able to occasionally do type assertions in an ergonomic way is surprisingly nice. - I wish Rust had something in the stdlib like net/http. - I like that go fmt is so unconfigurable and canonical. Here's where I would disagree: - I find ADTs (Rust's enums) super helpful for productivity. - Removing nil pointer derefs is wonderful, particularly for refactoring. - I spend too much time in Go rewriting bits of code that I would just use generics for in Rust or C++. Rust's iterators are wonderful and I end up using them over and over again. - Maybe it's my C background, but I like being able to occasionally use macros. Even for tests it makes things much more readable. - The borrow checker ends up moving many concurrency issues from runtime debugging to compile time debugging. - I think cargo is more pleasant to use to manage code than using go + godeps/glide/etc.
  • jdf 10y ago
    I forgot to add - I partially agree with you about the productivity of GC. For non-performance sensitive code, GC simplifies a lot. Otherwise, I find Go much nicer to reason about than Java since it has real arrays (value types!). But I find it a mixed bag of whether the naive Go version of something that shares memory by GC is simpler than the naive Rust version of something that shares memory. Sometimes ref-counting (Rc<T> in Rust) is fine, although that's more expensive than GC. Sometimes Rust's ownership model nudges you to make the code much simpler and makes it clear that something only has a single writer. Sometimes you wish you were in C and just did it yourself...
    • pcwalton 10y ago
      > Sometimes ref-counting (Rc<T> in Rust) is fine, although that's more expensive than GC. To nitpick: The jury's still out on that one, because Rc in Rust isn't thread-safe reference counting. I believe that non-thread-safe reference counting is quite competitive with global, cross-thread tracing GC. When people (rightly) talk about how much slower reference counting is than tracing GC, they're almost always talking about either thread-safe tracing GC vs. thread-safe reference counting or single-threaded tracing GC vs. single-threaded reference counting. When you compare Rc to a typical multithreaded GC'd language, you're comparing multithreaded tracing GC to single-threaded reference counting, which is a much more interesting comparison.
• pcwalton 10y ago
  > It's also important to note that Go was designed for programmer productivity and Rust wasn't. Rust was absolutely designed for programmer productivity. Source: I was one of the designers. > GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management. That's true, it is a productivity boost. But it also has a cost. Rust didn't want to pay that cost, especially when the same mechanisms are useful for preventing data races. (In fact, removal of GC was something that happened as a consequence of the data race freedom features; it wasn't a design goal from the beginning.) > Compile times in Go are a fraction of Rust compile times, which is another productivity boost. And rustc performs much more optimization. Again, a tradeoff. > Go gives you one good way to do concurrency, Rust believes in tyranny of choice. That's untrue. Go has threads, channels, mutexes, condition variables, and atomics. Rust has threads, channels, mutexes, condition variables, and atomics. The only thing I can think of that Rust has that Go doesn't is, like, SIMD, and I'm sure your comment wasn't just referring to SIMD.
  • jdf 10y ago
    > The only thing I can think of that Rust has that Go doesn't is, like, SIMD, and I'm sure your comment wasn't just referring to SIMD. Just to clarify, are you referring to Rust using SIMD by way of LLVM, or by way of being able to use SIMD primitives / intrinsics directly in Rust code? The former works much better than I had anticipated. I've been surprised by the extent that my iterator code ends up vectorized without me doing much work. The latter does not give me warm Rust feelings today. There's a SIMD crate, but it doesn't look maintained and only works with the nightly compiler releases. I didn't think there was any stable way to do inline assembly, so I think linking C is my best bet here?
    • Manishearth 10y ago
      > The latter does not give me warm Rust feelings today. There's a SIMD crate, but it doesn't look maintained and only works with the nightly compiler releases. I didn't think there was any stable way to do inline assembly, so I think linking C is my best bet here? Yeah, the person formerly working on simd is no longer able to contribute to random open source projects. It's still something the Rust team wants to make stable, just not right now. SIMD is a bit complicated because you need to address target support in a straightforward way.
• sidlls 10y ago
  As a long-time C++ developer I find I can be very productive writing Rust. Many modern C++ idioms translate almost directly to out-of-the-box Rust-isms. Some (including some important ones) don't, but these are relatively easy to understand and work with. Compile times are actually not that bad. I've seen some real doozies in my day, and plenty of hacks to overcome C++ compile times (distributed compiling, pre-compile steps to collect many dozens or more source files into a single TU, etc.). Rust is just fine. Besides, for the kinds of programs Rust is targeting being productive isn't synonymous with belting out as much code as fast as one can. As for concurrency, I think having options is great. There is rarely a one size fits all solution for concurrency and having choice mirrors real use cases very nicely. Furthermore I really enjoy generic programming. One of the worst parts of C is the lack of real generics. It gets tiresome writing the same array, hashtable, etc. code for each different type. Hiding it behind macros is terrible. It's one of many things that make both C++ and Rust superior to Go, in my view. That said, I do perceive a certain "feature my preferred language offers is the most important thing ever" myopia about some aspects of the Rust community. It's similar to a certain segment of the C++ community zealously beating the drum of "performance, performance performance" to the exclusion of other important things. Rust hasn't the popularity or use in the wild for its warts to be exposed yet, but time will tell. Every language has flaws and proper (and improper) uses.
• mythz 10y ago
  > GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management. Swift is a recent high-level productive language without a GC.
  • dikaiosune 10y ago
    Swift still has automatic memory management. It may not have a tracing GC, buy that's not super relevant from an ergonomics perspective (except that potential cycles require extra work/annotations).