3 ms·

I find it interesting that both Go and Rust, in practice, step on one of their relative foundational concepts. (2010: https://blog.golang.org/codelab-share http

I find it interesting that both Go and Rust, in practice, step on one of their relative foundational concepts. (2010: https://blog.golang.org/codelab-share https://blog.golang.org/codelab-share, for Go, and I suppose don't need to cite "safe system code" for Rust). For example, Go community could have stuck to their guns about building server side concurrent code only using channels and value objects, performance impact be damned, and we would not have high performance server code written in Go (using locks and shared memory). And as OP points out, "system level" code written in Rust likely will have (possibly opaque) unsafe code segments. Intent here isn't to rag on either language. It's more musing out loud about the impact of conceptual consistency in course of development on product success: is it a (practical) mistake to insist on it? Based on Go and Rust teams' decisions to date, it seems it pays to be pragmatic. (Or are we simply throwing the towel in too early?)

steveklabnik 7y ago
I'm not entirely sure. I think this line of inquiry is interesting, but I'm also not entirely sure that you're declaring Rust's original principles correctly. That is, the safe/unsafe dichotomy was always there. It's impossible to build real systems without it, and so I think that's why people gloss over it a bit. See slide 16 of http://venge.net/graydon/talks/intro-talk-2.pdf http://venge.net/graydon/talks/intro-talk-2.pdf, the original presentation of Rust to the world.
- eternalban 7y ago
  (I ~think Go also always had facilities for sharing memory as well. Don't remember.) The issue appears to be: - "It's impossible to build real systems" according to pure conceptual CS models, - or, our conceptual models are not sufficiently strong and expressive, and fall short bridging the gap between symbolic and physical realm, and these gaps manifest in code. - or that it's impossible to practically realize more complex conceptual models, and that even if possible, they would not be accessible to the general programming community. - or we're building on poor legacy foundations which will dog us until we finally rethink approaches from ground up. (Possibly those ORs are all ANDs.)
- leshow 7y ago
  Funny that the talk says "we are not rewriting the browser", given the current projects at mozilla.
  - steveklabnik 7y ago
    I always took that to mean "we are not doing the Big Rewrite."

steveklabnik 7y ago

I'm not entirely sure. I think this line of inquiry is interesting, but I'm also not entirely sure that you're declaring Rust's original principles correctly. That is, the safe/unsafe dichotomy was always there. It's impossible to build real systems without it, and so I think that's why people gloss over it a bit. See slide 16 of http://venge.net/graydon/talks/intro-talk-2.pdf http://venge.net/graydon/talks/intro-talk-2.pdf, the original presentation of Rust to the world.

eternalban 7y ago
(I ~think Go also always had facilities for sharing memory as well. Don't remember.) The issue appears to be: - "It's impossible to build real systems" according to pure conceptual CS models, - or, our conceptual models are not sufficiently strong and expressive, and fall short bridging the gap between symbolic and physical realm, and these gaps manifest in code. - or that it's impossible to practically realize more complex conceptual models, and that even if possible, they would not be accessible to the general programming community. - or we're building on poor legacy foundations which will dog us until we finally rethink approaches from ground up. (Possibly those ORs are all ANDs.)
leshow 7y ago
Funny that the talk says "we are not rewriting the browser", given the current projects at mozilla.
- steveklabnik 7y ago
  I always took that to mean "we are not doing the Big Rewrite."