4 ms·

I like Rust, but sometimes it is pretty difficult to convince the compiler that one's code is safe. And this does not mean that the compiler is preventing unsaf

I like Rust, but sometimes it is pretty difficult to convince the compiler that one's code is safe. And this does not mean that the compiler is preventing unsafety; there are many safe programs that the compiler rejects. Also, the OP said that compile time was a priority, and compiling Rust code is closer to C++ speed than C.

pdpi 11y ago
There are many valid programs that static typing rejects, too. Question is whether the trade off is worth it (and the answer isn't the same for everybody)
Manishearth 11y ago
> there are many safe programs that the compiler rejects It's often less about being safe currently and more about being resilient to breaking after further changes in code. I've worked with some C++ codebases that rely on complicated invariants to be safe (so the code looks safe now), and stuff breaks down when certain changes are made. Programming with a C++11 style greatly reduces but does not eliminate this. It takes a while to get a hang of this, but once you figure out the "Rust way" of moving data/references around you tend to hit these errors very rarely. Of course, this takes time to learn which you may not have :) But yes, there are things which Rust could improve upon here, like nonlexical scopes and SEME regions. Which may come soon.
pcwalton 11y ago
> And this does not mean that the compiler is preventing unsafety; there are many safe programs that the compiler rejects. Two nits: 1. The compiler does prevent safety problems. It just happens to rule out some safe programs while doing so. (Although I think this is a bit of a misconception, because with the aliasing rules being used for optimization many things that the Rust compiler rejects that people think are safe are actually not.) 2. You can describe any type system this way. That doesn't mean we don't like type systems.
- Jach 11y ago
  I think game programmers don't like type systems -- or rather, they prefer the minimal typing necessary for speed improvements and their ability to simplify basic static analysis (with tools or in their heads). I don't blame them, games are a lot of work even for relatively simple things, and to get anything done at a reasonable pace you just need to be able to churn out lots of code that compiles on the first try, and when it doesn't the mistakes should be easy to fix and minimize the time you're spending fighting with the type system (C++ templates come to mind as they're often avoided in games no small reason being the cryptic error messages they can produce). There might be an argument of familiarity, that eventually if they used Rust or Haskell enough it would all come to them as easy as C, but then well known Haskell promoters say things like "if you're using the type system right your code will never compile on the first time."
  - pcwalton 11y ago
    Well, it's the classic static versus dynamic typing debate, and the costs and benefits of each approach are well known at this point. In general, I think memory safety and data race freedom speed you up other than for small throwaway programs, because memory issues are so awful to debug (even with things like Valgrind).
  - tome 11y ago
    > the mistakes should be easy to fix and minimize the time you're spending fighting with the type system In Haskell you don't fight the type system. It fights your bugs. [Yes, yes, this isn't an absolute truth, but it is a relative truth when the point of reference is C++'s, or even Java's, type system.]

pdpi 11y ago

There are many valid programs that static typing rejects, too. Question is whether the trade off is worth it (and the answer isn't the same for everybody)

Manishearth 11y ago

> there are many safe programs that the compiler rejects It's often less about being safe currently and more about being resilient to breaking after further changes in code. I've worked with some C++ codebases that rely on complicated invariants to be safe (so the code looks safe now), and stuff breaks down when certain changes are made. Programming with a C++11 style greatly reduces but does not eliminate this. It takes a while to get a hang of this, but once you figure out the "Rust way" of moving data/references around you tend to hit these errors very rarely. Of course, this takes time to learn which you may not have :) But yes, there are things which Rust could improve upon here, like nonlexical scopes and SEME regions. Which may come soon.

pcwalton 11y ago

> And this does not mean that the compiler is preventing unsafety; there are many safe programs that the compiler rejects. Two nits: 1. The compiler does prevent safety problems. It just happens to rule out some safe programs while doing so. (Although I think this is a bit of a misconception, because with the aliasing rules being used for optimization many things that the Rust compiler rejects that people think are safe are actually not.) 2. You can describe any type system this way. That doesn't mean we don't like type systems.

Jach 11y ago
I think game programmers don't like type systems -- or rather, they prefer the minimal typing necessary for speed improvements and their ability to simplify basic static analysis (with tools or in their heads). I don't blame them, games are a lot of work even for relatively simple things, and to get anything done at a reasonable pace you just need to be able to churn out lots of code that compiles on the first try, and when it doesn't the mistakes should be easy to fix and minimize the time you're spending fighting with the type system (C++ templates come to mind as they're often avoided in games no small reason being the cryptic error messages they can produce). There might be an argument of familiarity, that eventually if they used Rust or Haskell enough it would all come to them as easy as C, but then well known Haskell promoters say things like "if you're using the type system right your code will never compile on the first time."
- pcwalton 11y ago
  Well, it's the classic static versus dynamic typing debate, and the costs and benefits of each approach are well known at this point. In general, I think memory safety and data race freedom speed you up other than for small throwaway programs, because memory issues are so awful to debug (even with things like Valgrind).
- tome 11y ago
  > the mistakes should be easy to fix and minimize the time you're spending fighting with the type system In Haskell you don't fight the type system. It fights your bugs. [Yes, yes, this isn't an absolute truth, but it is a relative truth when the point of reference is C++'s, or even Java's, type system.]