3 ms·

Yeah, I've run into that same issue with kubeadm. It was hanging because of the network not being set up. I'm not really sure where your original comment is go

Yeah, I've run into that same issue with kubeadm. It was hanging because of the network not being set up. I'm not really sure where your original comment is going, but I don't really feel the problem is endemic to Go. Using/debugging most software is an exercise in frustration. Just look at Linux on the desktop (which I use btw, I'm not criticizing). Fixing things is usually reduced to tribal knowledge, IRC, and Googling.

erikb 9y ago
I agree, a lot of software NOT written in Go also has this problem. I don't know how it is in C world, but in many programming languages wriitng good activity reporting (i.e. logging) is considered a core skill of each program. It is sometimes hard to read the logging messages and understand how they came to be. But just having a different status report for a different problem is already so helpful. For instance if kubeadm fails with "I need cheeseburgers" when you actually forgot to configure your proxy correctly, and with "I need more minerals" when you forgot something else, then the first time debuggin is quite frustrating. But after that you know "cheeseburger means proxy" and you can continue. But if you hit "waiting for control plane" for ALL the problems, then your brain can't even remember for what to check right now. I'm the best example, I already forgot the other five things that can go wrong and I would need to check my work internal wiki for that. I think that's the main reason why logging exist, to increase the speed of hitting a symptom to discovering what's actually going wrong. And Go in general, k8s specifically, simply goes in the other direction the whole time. They don't report any errors, and sometimes even report errors when there is no error. This is systematic in some way but I would need to study the community to tell you more specifically what's wrong.

erikb 9y ago

I agree, a lot of software NOT written in Go also has this problem. I don't know how it is in C world, but in many programming languages wriitng good activity reporting (i.e. logging) is considered a core skill of each program. It is sometimes hard to read the logging messages and understand how they came to be. But just having a different status report for a different problem is already so helpful. For instance if kubeadm fails with "I need cheeseburgers" when you actually forgot to configure your proxy correctly, and with "I need more minerals" when you forgot something else, then the first time debuggin is quite frustrating. But after that you know "cheeseburger means proxy" and you can continue. But if you hit "waiting for control plane" for ALL the problems, then your brain can't even remember for what to check right now. I'm the best example, I already forgot the other five things that can go wrong and I would need to check my work internal wiki for that. I think that's the main reason why logging exist, to increase the speed of hitting a symptom to discovering what's actually going wrong. And Go in general, k8s specifically, simply goes in the other direction the whole time. They don't report any errors, and sometimes even report errors when there is no error. This is systematic in some way but I would need to study the community to tell you more specifically what's wrong.