371–380 of 425 posts
Earlier quoted context omitted.
Absolutely. But those are clear code smells. Any org with competent code review would flag them and kill them before they proliferated.
Have you seen the internals of the Go http library? :)
Earlier quoted context omitted.
Would you consider k8s to be developed by a competent org? They have 2324 func declarations that take or return an interface{} on master right now.
Kubernetes, like Docker, is notoriously bad Go. The authors essentially transliterated Java.
Earlier quoted context omitted.
How returning (val, err) is error prone? It's verbose but it's clear and definitely not error prone. I spent so much time working with Java and useless giant stacktraces or with Python and people not knowing what to do inside a try / except.
Copy/paste is very error prone. Golang code is full of it. I see lots of similarities between Visual Basic and Golang, incl. the passionate communities behind the languages.
Earlier quoted context omitted.
> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics. That lead to a world where folks felt "forced" to use Java, and that's a sti…
You can't compare it to Java checked exceptions. Java checked exceptions are one of those billion dollar "mistakes". It is the single worst thing in Java for me. Checked exceptions add nothing and break almost everything around clean design & code. For that comparison to work, java would have needed to only have checked exceptions, with some added language features to deal with them cleanly, and then it might actuall…
And even C++, after dropping exception specifications in C++17, might get a simplified version back in C++23 as part of value based exceptions proposal.
Earlier quoted context omitted.
> Littering your code with try-catch is what makes exceptions infeasible for error handling. I honestly don't see the big difference between littering your code with if/else blocks versus littering them with try/catch blocks. Can you elaborate?
If/else provides a clear and easy to follow control flow. try/catch is like a roaming goto that works it's way back up your stack in ways you can't predict. http://www.lighterra.com/papers/exceptionsharmful/
Earlier quoted context omitted.
> Littering your code with try-catch is what makes exceptions infeasible for error handling. I honestly don't see the big difference between littering your code with if/else blocks versus littering them with try/catch blocks. Can you elaborate?
Both are bad.
Earlier quoted context omitted.
The controversy may have died down, but the impact on code written would have been permanent. There's a lot of value to there being "one way to do things", even when it's not the best way from any particular point of view. Go holds this principle higher than most other languages and I think that should be either embraced, or one should look elsewhere - and I'm saying that as someone who "looked elsewhere".
Agreed, no one is forced to use Go. I think it is refreshing to see a language like Go. You don't want all languages to asymptotically approach each other in features. We need diversity in our languages, that way you have flavors to choose from.
Using a programming language is not always an option.
Earlier quoted context omitted.
Typing “if err != nil { return nil, err }” a million times is not thought.
To be fair, any decent editor will expand 'er' to that, no need to type it manually.
Earlier quoted context omitted.
Experts' code should be clearer and more concise than novices' code. If that's not true, there's no payoff for getting more proficient with the language, and it's not doing enough to help you.
golang is not primarily designed for experts "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to und…
Earlier quoted context omitted.
If/else provides a clear and easy to follow control flow. try/catch is like a roaming goto that works it's way back up your stack in ways you can't predict. http://www.lighterra.com/papers/exceptionsharmful/
The context here is Java's checked exceptions, which have to be handled explicitly at the site where they may occur, leading to control flow that - in my view - isn't substantially different from handling errors with if/else.