> at least it is largely passed us now

What does this mean? There doesn't seem to be a popular alternative to C++ yet, unfortunately.

▲ klardotsh 4 hours ago | parent [-]

Aside from game dev, Rust is being used in quite a lot of green field work where C++ would have otherwise been used.

Game dev world still has tons of C++, but also plenty of C#, I guess.

Agreed that it’s not really behind us though. Even if Rust gets used for 100% of C++’s typical domains going forward (and it’s a bit more complicated than that), there’s tens? hundreds? of millions (or maybe billions?) of lines of working C++ code out there in the wild that’ll need maintained for quite a long time - likely order decades.

▲ Animats 3 hours ago | parent [-]

The problem in Rust is that if B is inside of A,

    struct A {
        name: String,
        owned: B
    }

    struct B {
        name: String,
    }

you can't have a writeable reference to both A and B at the same time. This is alien to the way C/C++ programmers think. Yes, there are ways around it, but you spend a lot of time in Rust getting the ownership plumbing right to make this work.

	▲	anon291 24 minutes ago \| parent \| next [-]
		It's kind of crazy that OOO is sold to people as 'thinking about the world as objects' and then people expect to have an object, randomly take out a part, do whatever they want with it and just stick it back in and voila This is honestly such an insane take when you think about what the physical analogue would be (which again, is how OOP is sold). The proper thing here is that, if A is the thing, then you really only have an A and your reference into B is just that, And should be represented as such, with appropriate syntactic sugar. In Haskell, you would keep around A and use a lens into B and both get passed around separately. The semantic meaning is different.
	▲	vlovich123 2 hours ago \| parent \| prev [-]
		> you can't have a writeable reference to both A and B at the same time > but you spend a lot of time in Rust getting the ownership plumbing right to I think you maybe meant to say something different because here's the most obvious thing: `impl A { fn simultaneously_writeable(&mut self) -> (&mut str, &mut str) { (&mut self.name, &mut self.owned.name) } }` Now it may take you a while to figure out if you've never done Rust before, but this is trivial. Did you perhaps mean simultaneous partial field borrows where you have two separate functions that return the name fields mutably and you want to use the references returned by those functions separately simultaneously? That's hopefully going to be solved at some point, but in practice I've only seen the problem rarely so you may be overstating the true difficulty of this problem in practice. Also, even in a more complicated example you could use RefCell to ensure that you really are grabbing the references safely at runtime while side-stepping the compile time borrow checking rules.