4 ms·

In theory yes, but when you look at the average Rust program, those mechanisms are avoided in favor of more idiomatic approaches.

hgomersall 5y ago
Interior mutability is used all over the place. It's absolutely necessary. The thing is you are forced to be clear about the runtime safety mechanism you're using. In general, it gets abstracted away behind a safe API.
- verdagon 5y ago
  Indeed it's present under the hood, we are operating on a CPU after all, which treats all of RAM as one giant shared-mutable blob of data. It will always be there, under some abstraction. The point I'm trying to communicate is that in practice, for various reasons, Rust programs do not use shared mutable access to objects to the same extent that C++ programs do. For example, C++ programs use observers, and dependency injection (the pattern, not the framework) to have member pointers to mutable subsystems, and we just don't often see that in Rust programs. This is the paradigm mismatch I'm highlighting: to rewrite a C++ program in Rust often requires a large paradigm shift. The pain is particularly felt when making them interoperate in a gradual refactoring. This is IMO one the bigger reasons that big rewrites to new languages fail, and why new languages benefit from being multi-paradigm, so that there's no paradigm mismatch to impede migrations.
  - westurner 5y ago
    IDK why the private, internal paradigms of e.g. Spanner would even need to be reimplemented in a clone instead of a port? Looks like CockroachDB (Go), TiDB (Go, Rust), and YugabyteDB (C++) are Distributed SQL alternatives to Spanner. ... Which may or may not be able to rely upon inexpensive Lamport clocks: https://en.wikipedia.org/wiki/Lamport_timestamp#Lamport's_logical_clock_in_distributed_systems https://en.wikipedia.org/wiki/Lamport_timestamp#Lamport's_lo...
    - ceeplusplus 5y ago
      All those alternatives you mentioned are nowhere close to being on the level of Spanner in reliability or performance, particularly in a high contention scenario.
      - westurner 5y ago
        According to which objective metrics?
    - westurner 5y ago
      From https://westurner.github.io/hnlog/#comment-30603322 https://westurner.github.io/hnlog/#comment-30603322 re https://en.wikipedia-on-ipfs.org/wiki/Database_index https://en.wikipedia-on-ipfs.org/wiki/Database_index : https://github.com/wilsonzlin/edgesearch https://github.com/wilsonzlin/edgesearch : > * Serverless full-text search with Cloudflare Workers, WebAssembly, and Roaring Bitmaps * > "Edgesearch builds a reverse index by mapping terms to a compressed bit set (using Roaring Bitmaps) of IDs of documents containing the term, and creates a custom worker script and data to upload to Cloudflare Workers" WASM or [C++] to WASM? TIL about Roaring Bitmaps: /?q=roaring+bitmap https://medium.com/@amit.desai03/roaring-bitmaps-fast-data-structure-for-inverted-indexes-5490fa4d1b27 https://medium.com/@amit.desai03/roaring-bitmaps-fast-data-s...

hgomersall 5y ago

Interior mutability is used all over the place. It's absolutely necessary. The thing is you are forced to be clear about the runtime safety mechanism you're using. In general, it gets abstracted away behind a safe API.

verdagon 5y ago
Indeed it's present under the hood, we are operating on a CPU after all, which treats all of RAM as one giant shared-mutable blob of data. It will always be there, under some abstraction. The point I'm trying to communicate is that in practice, for various reasons, Rust programs do not use shared mutable access to objects to the same extent that C++ programs do. For example, C++ programs use observers, and dependency injection (the pattern, not the framework) to have member pointers to mutable subsystems, and we just don't often see that in Rust programs. This is the paradigm mismatch I'm highlighting: to rewrite a C++ program in Rust often requires a large paradigm shift. The pain is particularly felt when making them interoperate in a gradual refactoring. This is IMO one the bigger reasons that big rewrites to new languages fail, and why new languages benefit from being multi-paradigm, so that there's no paradigm mismatch to impede migrations.
- westurner 5y ago
  IDK why the private, internal paradigms of e.g. Spanner would even need to be reimplemented in a clone instead of a port? Looks like CockroachDB (Go), TiDB (Go, Rust), and YugabyteDB (C++) are Distributed SQL alternatives to Spanner. ... Which may or may not be able to rely upon inexpensive Lamport clocks: https://en.wikipedia.org/wiki/Lamport_timestamp#Lamport's_logical_clock_in_distributed_systems https://en.wikipedia.org/wiki/Lamport_timestamp#Lamport's_lo...
  - ceeplusplus 5y ago
    All those alternatives you mentioned are nowhere close to being on the level of Spanner in reliability or performance, particularly in a high contention scenario.
    - westurner 5y ago
      According to which objective metrics?
  - westurner 5y ago
    From https://westurner.github.io/hnlog/#comment-30603322 https://westurner.github.io/hnlog/#comment-30603322 re https://en.wikipedia-on-ipfs.org/wiki/Database_index https://en.wikipedia-on-ipfs.org/wiki/Database_index : https://github.com/wilsonzlin/edgesearch https://github.com/wilsonzlin/edgesearch : > * Serverless full-text search with Cloudflare Workers, WebAssembly, and Roaring Bitmaps * > "Edgesearch builds a reverse index by mapping terms to a compressed bit set (using Roaring Bitmaps) of IDs of documents containing the term, and creates a custom worker script and data to upload to Cloudflare Workers" WASM or [C++] to WASM? TIL about Roaring Bitmaps: /?q=roaring+bitmap https://medium.com/@amit.desai03/roaring-bitmaps-fast-data-structure-for-inverted-indexes-5490fa4d1b27 https://medium.com/@amit.desai03/roaring-bitmaps-fast-data-s...