On 2020-02-07 08:56, Michel Levieux wrote: > I'd like to add that for this particular purpose, I find the keyword "try" > quite > inappropriate.
When I did "Systems Programming" they didn't even teach C itself but rather some C library functions, which wasn't very helpful when I look back on it. I worry that Go may become convoluted over time. I guess I am fairly new to Go and with a C background but I still see methods and even error unwrapping as needless complexity even though they are simple constructs. In C, I avoid function pointers for security reasons and if the line isn't too long I shall even avoid |= because it provides less clarity, so one liners with multiple methods, irritate, rather than please me. In Linux you have multiple bridge tools and IP tools and some say this is good as people can choose but the older brctl with a man page that enabled me to do what I needed quickly, is deprecated. Competition is good but it should compete against the existing tool. So having multiple tools might please everyone theoretically but that doesn't mean that it isn't adding complexity or causing issues, and pointless learning curves should carry weight in decisions. Being able to return multiple things and an error and having the line logged for you without even writing an error function as I would in C has been perfect and a no-brainer. I am just hoping that wanting to import something or using the std lib doesn't mean you have to waste time learning another obfuscation (personally, I see methods as unnecessary already). -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/84fd0066-550e-5d3e-193f-f9b1928e61b2%40gmail.com.
