4 ms·
> A big problem, among many, with doing that is that you leak implementation details out of the abstraction. If, to stick with your example, you have a function
by still_grokking 4y ago
> A big problem, among many, with doing that is that you leak implementation details out of the abstraction. If, to stick with your example, you have a function that helps you with reading files, the caller shouldn't care where the data is stored. Today it might be the local filesystem, tomorrow S3, and when you make that change nothing about the rest of the program should break.
This would lead to the situation where a local call is treated as the same thing to a network call. Which is know to be a very bad design.
> Like the sibling comment points out, Rust does "from" conversion when using try (?) to try and avoid encountering the same fate.
Yeah, and it avoids all the hassle.
Why couldn't any language (and especially Go) just do the same?
- randomdata 4y ago> Which is know to be a very bad design. If your abstraction leaks that the implementation is a local call, and then you try and change that later, unquestionably. Again, you need to avoid leaking implementation details, which is too why you can't just add a try operator and make it automatically useful. Any leak of any kind in your abstraction will make life miserable later. Don't let your abstraction leak. > Yeah, and it avoids all the hassle. All it does is move where the code is located, placing the onus on the producer "the producer is always right" instead of the caller "the customer is always right". You don't actually avoid anything, just change the perspective. > Why couldn't any language (and especially Go) just do the same? Perhaps it could, but it requires that the language take a more macro look at the problem. It is not a microfeature.
- deleted 4y ago[deleted]