4 ms·
Surely not "because of the borrow checker", since it's trivial to relax its enforcement with very limited runtime overhead. The tasks that essentially require G
by 0815test 7y ago
Surely not "because of the borrow checker", since it's trivial to relax its enforcement with very limited runtime overhead. The tasks that essentially require GC (and this is pretty much always the case, even wrt. C!) are those where you're dealing with general graphs, potentially with cycles, and where the overall profile is such that you can't simply deal with it by allocating everything within an arena and then wiping it when you're done. This is where something like LISP traditionally shines, but Go of course ships with a well-designed concurrent GC that makes it a viable candidate in this space.
- pjmlp 7y agoCertainly because of the borrow checker, try to implement a GUI using Gtk-rs to see how much fun it is, to the point that even the samples use macros to reduce the boilerplate of accessing widget data from event handler callbacks.