"There's simply no way to tell the compiler to not drop a variable automatically when it goes out of scope."
Perhaps std::mem::forget
Why I’m dropping Rust
101–110 of 164 posts
Re: Why I’m dropping Rust
#102Wasn't really able to follow the bit about traits but:
It seems like if you want to have back-references you either would need to use Rc> or Arcs, which is not the end of the world.
The best way to do it would be to not have back references at all. Then you could simply have Vec> for children.
If I were going to build a GUI system in rust I certainly wouldn't design it to be OO. I think you would repeatedly run into problems. An entity component system or something like react might work better in rust.
Re: Why I’m dropping Rust
#103Earlier quoted context omitted.
"Safe" Rust works for almost everything in a typical CS curriculum. But if you want to teach an operating systems course or build cyclic, pointer-based data structures, you'll usually need a modest amount of "unsafe" Rust. Using "unsafe" gives you access to real pointers, which work just like they do in any systems language. It's just that Rust chooses to lock those features away when you don't explicitly ask for the…
Where did you learn CS that they didn't have lots of cyclic data structures? We had those even in our intro class at Berkeley...
I a few universities I know, including my own, cyclic data structures are on the curriculum, but nowhere near being taught as basic or intro stuff. That would lists, queues, trees, and hash-maps.
Re: Why I’m dropping Rust
#104Earlier quoted context omitted.
Why? It would be fair if he was trying to push a product, but here it's just a technical discussion.
I am not claiming that he is pushing the product, just that his opinion can be biased, but then how would you want to push clearly technical product like Rust without technical discussion?
It's probably worth noting that a lack of affiliation would not imply a lack of bias.
Re: Why I’m dropping Rust
#105Earlier quoted context omitted.
Where did you learn CS that they didn't have lots of cyclic data structures? We had those even in our intro class at Berkeley...
I a few universities I know, including my own, cyclic data structures are on the curriculum, but nowhere near being taught as basic or intro stuff. That would lists, queues, trees, and hash-maps.
The regular LinkedList in Java is implemented as a doubly linked list, which is cyclic.
Re: Why I’m dropping Rust
#106Earlier quoted context omitted.
While disclaimers are common (for some reason), it has no effect on the virtue of his points. It's just fluff.
I have different opinion on that matter. Sure, some of his points are valid, I even agree with some of them but not all and not always. That's why disclaimers exist, for that reason. Especially when there are cases of glorifying your own product and bashing others. Please read this: https://en.wikipedia.org/wiki/Bias
The purpose of disclaimers is to preemptively shut up bozos that would accuse you of commenting in bad faith, not because it's right to do.
And it isn't bias if you're right.
Re: Why I’m dropping Rust
#107Earlier quoted context omitted.
> GUI libraries are an interesting special case: They involve huge class hierarchies, lots of implementation inheritance, circular references, and tricky ownership. I doubt they have to be. There are other ways to do GUI, see for instance how Light Table uses a database-like Entity Component System. https://www.youtube.com/watch?v=V1Eu9vZaDYw
I am fairly confident "someone" could write a composition-based UI. I know of no fundamental reason why that would be impossible, or even any more difficult than doing one with inheritance. However, that does not solve the problem that all the mature existing UI widget toolkits are based on inheritance, and that causes a serious "impedance mismatch" with languages that don't have inheritance. As I expect more languag…
You might be able to create something like React. The API would be composition-based, and the library would bottom out against an existing UI toolkit.
Re: Why I’m dropping Rust
#108I don't know anything about Rust itself but I find it amusing that the author thought that six months should have been more than enough time for the community to agree on and implement a nontrivial change in how the language works.
When I saw "at least since March 2016," I wondered if it was a typo.
Re: Why I’m dropping Rust
#109It seems the author is trying to do classical OOP using traits (type classes). They aren't a match although the similarities. I understand his rant, but I don't think it is a valid one. You must change your design or change your tool, he opted to change the tool.
I hit the same wall, and opted to learn a new way of design after years of slavishly adhering to OOP.
There's not much that I miss from OOP, and I now see its utility as more about making the ability to program scale predictably with an unpredictable workforce.
Re: Why I’m dropping Rust
#110Earlier quoted context omitted.
In what conceivable way? Safe Rust allows one to do an incredible amount of things whole providing strong guarantees against the sorts of problems that plague lower level languages. Since this isn't suitable for absolutely everything, we have unsafe Rust to fill in the gaps in the small areas it's needed. Unsafe Rust isn't "bad", it just doesn't provide the same guarantees as safe Rust. And if something goes wrong, y…
I'm not convinced that cyclic data structures are a feature that's exotic enough to warrant breaking the language contracts. This thread alone shows that it's a common occurrence in tree structures. There will be likely be other structures as well. So I'd think a better way than saying "don't do that - or if you have to, you're on your own" would be to analyze use cases and see which scenarios the language can satisf…
Agree. The language's memory safety system needs to support more common use cases. At least:
- Back pointers. (They're not owning pointers, and they have a well defined relationship with some other pointer. The language may need some way to explicitly say that.)
- Collections where not all slots are initialized. (This requires simple proofs by induction as you grow a collection into previously allocated unused space.)