[nitsky]

> I optimize directly for the hardware I'm running on, which typically gives me 10-100x performance improvements. Controlling how memory is managed is critical.

What makes you think you can't control how memory is managed in Rust? Rust doesn't have "automatic" memory management, it has a compiler that can help ensure you are managing memory correctly, and force you to type "unsafe" when you are doing things it doesn't understand.

[Galanwe]

> it has a compiler that can help ensure you are managing memory correctly, and force you to type "unsafe" when you are doing things it doesn't understand.

Well it's a bit more subtle than that if we're honest.

Arguably, Rust does make a number of memory layouts (self referential structs, per struct allocators, non thread local addresses, etc) much harder to accomplish than "typing unsafe".

[wizzwizz4]

If you self-reference using pointers and guarantee the struct will never move, you don't even need unsafe. If you self-reference using offsets from the struct's base pointer, you need a splash of unsafe but your struct can be freely moved without invalidating its self-referential "pointers".

Per-struct allocators are a work in progress (see https://github.com/rust-lang/wg-allocators/issues/48).

Not sure what "non thread local addresses" means, but in my experience Rust is pretty good at sending data between threads (without moving it).

[Galanwe]

> If you self-reference using pointers and guarantee the struct will never move, you don't even need unsafe

I have a hard time seeing how you could use self references without a combination of raw pointers, pins/projects, and unsafe code. The tediousness of doing so is pretty much a no-go for any sane developer.

The only sane solution seems to be a generous sprinkle of Arcs, which is _not_ okay in high performance scenarios.

> Per-struct allocators are a work in progress

Yes, and most of us don't really want to use nightly in production. It's been years of work on the allocator work group already, and there's probably still years to wait before a stable release.

> Not sure what "non thread local addresses" means, but in my experience Rust is pretty good at sending data between threads

Well I mean overall any way to allow a somewhat eased setup for storing and retrieving objects to/from shared memory, across processes that do not map said memory at the same location. This is very very annoying to implement in Rust at the moment.

Don't get me wrong though, I think Rust has a lot to offer. But when you dive in even slightly technical subjects in Rust, it soon becomes obvious that the power of C/C++ is far from "just type unsafe" away.

[wizzwizz4]

> I have a hard time seeing how you could use self references without a combination of raw pointers, pins/projects, and unsafe code. The tediousness of doing so is pretty much a no-go for any sane developer.

You just do it. I can't recall a good example at the moment, so I've just thrown together a load of Cells: the thing I was doing when I learnt this technique didn't have any Cells in it.

https://play.rust-lang.org/?version=nightly&edition=2021&gis...

  #[derive(Debug)]
  struct SlotMachine<'a> {
    slots: Vec<Cell<i32>>,
    current: Cell<Option<&'a Cell<i32>>>,
  }

  fn main() {
    let machine = SlotMachine {
        slots: vec![Cell::new(0); 5],
        current: Cell::new(None),
    };
    machine.current.set(Some(&machine.slots[4]));
    machine.slots[4].set(12);
    println!("{:#?}", machine);
  }

> Yes, and most of us don't really want to use nightly in production.

Strictly speaking, this is only needed if you want to use Rust's standard library types with custom allocators. You've been able to have per-struct allocators for your own types since long before I learnt the language.

> Well I mean overall any way to allow a somewhat eased setup for storing and retrieving objects to/from shared memory, across processes that do not map said memory at the same location.

Can't you just store offsets into the memory region, and PhantomData references, then unsafely index the mmap'd region when you need an actual reference? Seems like the same thing you'd do in C, except the function you abstract that with can be a method instead. (Unless I'm still misunderstanding.)

[B8MGHCBekDuRi]

> What makes you think you can't control how memory is managed in Rust?

experienced C++ programmers says "Rust is great but very young and still C++ is better for my use case".

Rust supporter replies "what makes you think you know better than us what it is better for you?"

Welcoming community, they said.

[Shish2k]

Neither of those paraphrasings seem to line up with their source material

[B8MGHCBekDuRi]

Are you sure?

Read again

> I optimize directly for the hardware I'm running on, which typically gives me 10-100x performance improvements. Controlling how memory is managed is critical.

> What makes you think you can't control how memory is managed in Rust?

> Arguably, Rust does make a number of memory layouts (self referential structs, per struct allocators, non thread local addresses, etc) much harder to accomplish than "typing unsafe".

So basically, the right question would be "can you explain what you mean that Rust can't control how memory is managed"?

Because the author knew, the Rust supporter didn't and confused "work in progress" with "I need it now because I'm using it now in production in my daily job"

[Shish2k]

Yup, I’ve read it again, and I’m still pretty sure that you’re responding mostly to your own assumptions and not really responding to what was written :)

[B8MGHCBekDuRi]

We've established that you lack the ability to understand a text, then.