3 ms·

> significant cognitive burden (...) I'm very skeptical that it ever gets to the point of a GC language My experience in this regard: Once you stop thinking in

• throwaway894345 7y ago
  I'm already on-board with data-oriented design, and my pedigree includes lots of such projects and languages (C, C++, Go, etc). I'm also familiar with Rust; I've been dabbling in it since ~2014. Still, I come to opposite conclusions. Rust is a magnificent language for many things, but I'm manifold more productive in Go or Python, even in concurrent contexts. Notably, the ownership rules guarantee correctness, but they also prohibit all sorts of correct programs (e.g., functions that only run in a single threaded context or whose shared data doesn't actually mutate). I would say I have the hang of these rules, but I still struggle to make sense of the lifetime error messages (and I find this nearly impossible when I'm tired), contrary to your experience about the clarity of the compiler messaging. I don't mean to slight the compiler--communicating about lifetimes is fundamentally hard; however, the point is that these error messages must be dealt with in all code even though the overwhelming majority of my code isn't subject to race conditions in the first place. I really want to like Rust (I love it in theory); however, frankly I don't see how Rust can approach a GC language with respect for productivity for anyone unless the domain prioritizes correctness and/or performance above all else.
  • lukebitts 7y ago
    > I don't see how Rust can approach a GC language with respect for productivity for anyone My domain is games, and while this usually prioritizes performance that's not really what I care about (so I could be using Python for instance and it would be 'ok'). My take is this: When it comes to productivity even if writing the same code is easier in Python than Rust, working over time in a Python project (or any dynamic language really) is just a nightmare for me. No matter how many tests I write or how I structure my code when I have to add a new feature that touches large parts of the existing system I just have 0 confidence it is correct. I have to run my code through all the branches to make sure I didn't forget to, idk, add the new parameter to all function calls or something. Rust on the hand is just reliable. I can start updating my code with a half baked idea, start adding types to things, removing parameters from functions, changing variables names and I KNOW nothing will sneak on me during runtime. This is more of a feature of strong type systems than Rust itself, but still this is what productivity means to me. (Also, to me lifetimes were the hardest concept to grasp, but I think once you really get what they mean that's when the language clicks and you get the same productivity you would elsewhere)
    • throwaway894345 7y ago
      Fully agree that (all else equal) static type systems are more productive than dynamic type systems; however, that's mostly orthogonal to GC vs Rust's ownership model. I agree that Rust's ownership model provides for more correctness than GC, but at the expense of a whole lot of productivity (which was my original point). I also think the returns on static type systems (and static analysis in general) diminish quickly after (roughly) Go's position on the axis. To be clear, I would like to see Go have a more expressive type system (generics and sum types), but I think Go recoups upwards of ~90% of the quality difference between untyped Python and Rust (for example) while still allowing you to be at least as productive as with Python (which is still about 90% more productive than with Rust IMO). Disclaimers: this is all super subjective, error margins are huge, and YMMV.
      • dpc_pw 7y ago
        I would take Go over Python, any day. It is productive, especially if your program is a relatively typical network service: get request, poke here and there, transform this into that, return a result. It looses steam when the code is abstract logic or generics/macros heavy. Also, I personally loose quite a bit of time on debugging these couple of pesky issues that I always get introduced by `nil`, lack of sum types, some Go gotchas etc. In practice the most important things for general productivity are always: what is your team familiar with, what are you familiar with, and are the types of libraries that you need available. Quite often these are skewed in Go's favor.
• jkoudys 7y ago
  It really is downright shocking sometimes how much gets caught by the rust compiler. It's the first time in my life when I feel like code is likely to actually work once the compiler comes back clean.