3 ms·

To put it bluntly: there's already one too many languages that make one bend into a pretzel to satisfy a tool. If D tried to humanize C++, which is not a given

• fauigerzigerk 7y ago
  If the overhead of automatic GC doesn't fit your project you only have two choices: a) Keep all the ownership and lifetime information in your head and make sure it gets communicated to other team members. Then write tests to make sure nothing was missed. b) Formally specify ownership and lifetime so it can be checked by the compiler. I'm not sure (a) is any less dehumanizing than (b)
  • blub 7y ago
    Between A and B there's quite a few type system tricks & tools that one can use which bring many benefits without incurring the costs of fully verified memory ownership. I stand by my original statement though: a) in a language like C and C++ one has to use their knowledge to come up with a solution and verify it. Pretty human. b) in a GC language, one mostly does not care. When they do, they do a). c) in Rust one does their best at a) and then does what the robot tells them to, even if the code is correct but the robot can't yet figure it out.
• pjmlp 7y ago
  For Rust I am still looking forward to not having to scatter Rc<RefCell<>> everywhere when using Gtk-rs and similar UI toolkits.
  • aldanor 7y ago
    Not too familiar with inner workings of gtk-rs, but: would ECS approach work there? Or e.g., a generational slotmap, so you could pass around copyable integer keys as much as you want.
    • pjmlp 7y ago
      And then eventually get use-after-free access errors unless I use vector clocks to keep track of indexes usage, or reach to a third party library that does it for me.