> You are misunderstand me. I'm saying you could type the following by mistake: if foo() { bar() } else { baz() } Then there wouldn't be a variable assigned

> You are misunderstand me. I'm saying you could type the following by mistake: if foo() { bar() } else { baz() } Then there wouldn't be a variable assigned to use in the first place. This is not the issue at hand here. > Actually yes. You'd get the following error: b declared and not used The first line I wrote declared and assigned to b, but in the if/else statement, b was overridden, so the error you mentioned won't happen, it will simply get overridden and a bug would happen. > "Why do you find it so hard to accept that other people might like something you don't?" It seems most people don't realize the other advances in languages designed to reduce errors, which golang discards on purpose and without good reason, and they just accept the hype and marketing around golang. You keep hearing that golang's gc is the best gc around and things to that extent, clearly incorrect nonsense. > Your argument is that Go isn't suitable and I was evidencing how it is used in the very fields you assumed it couldn't. The argument is that you can use any (badly) designed language to write large software, it will just end up costing more effort and resources (e.g. see javascript or large programs written in ruby and python, they're doable, but with a very large cost). Using things better suited for the task at hand is important, especially seeing how software these days is not up to par. Then you have another badly designed language (golang) that decides on purpose to ignore research done to improve software reliability, it's not a surprise things the way they are. > It was the comments about how people who are clearly more experienced than you seemingly know jack shit in your outspoken opinion. Being more experienced doesn't mean not falling into a closed way of thinking, which clearly shows if you follow the golang authors and their history. This is an appeal to authority fallacy. > And C and assembly are well suited for some specific domains as well. That's not the point of discussion. The point is that for practically anything other than some small tool type work (even there it's arguable), there are other strictly superior offerings. > to try and convince you to use Go I already use it at work, that's how I'm aware of it's enormous shortcomings, by using it myself, and hearing and seeing how others use it and complain about it as well. That's why it's a fad, the company is quite invested in it now so it's difficult for them to switch, so they have to find hacks to deal with its shortcomings.