I mostly agree, but there are times when abstraction leads to complex code and more reasonable approach involves documented constraints. The map type is not safe either, but it enjoys widespread use. If it were abstracted to handle all possible use-cases, it would be unnecessarily slow for most of the operations its used for.
There's an illusion of safety in languages that advertise all-encompassing abstractions, in my experience the problem becomes the language or library itself, as the underpinnings acquire code bloat to cover all use-cases. If this happens, the user must now choose between unboxing the black box or writing their own (better/stronger/faster) language/package. Knowing 5-10% of a package implementation details seems like a reasonable tradeoff for a simpler implementation. On Friday, June 24, 2016 at 7:12:11 PM UTC-7, Henry wrote: > > Libraries should be more like black boxes. The user shouldn't need to know > about their implementation, be it concurrent or not. It is the libraries' > responsibility to ensure any data passed to them is safe. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
