21–30 of 526 posts
Out of all the bugs which Go permits I have yet to see one which could survive in production for some time without being discovered. Almost all of them would cause a failure the first time a segment of code is run.
I guess I feel bad for people who are particularly sensitive to the areas that Go does not succeed in, because they are probably going to be complaining about it for the rest of their lives. The truth is though, I don't use a bunch of rationale about what is the best programming language to choose which one to work on for a project, I choose a language that I feel works well for me, that I feel I can consistently write good software in, that feels, well, nice to work in. Being a person that values correctness, I do sort of wish that language could be something more like Rust, but for now, it's just not, though it's not like I hate Rust, it's just not what I reach for in a pinch.
Enough has been written about how terrible Go is by this point. At least now I know what it's like to have been a fan of PHP a few years ago! (That's an exaggeration, but it's not that big of one in my opinion.)
This article makes a lot of great points about the shortcomings of Go. I don’t think explicit error handling is one of them however. I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up. From a technical standpoint that isn’t necessarily a good argument, but from a pragmatic standpoint and decades of experience… well I will take expl…
When I started trying to teach myself Rust, the error handling story fell apart on me very quick. Like as soon as I wanted to try and get sensible reporting in their, suddenly we were relieving libraries, adding shims and fighting mismatched types and every article was saying the same thing: haha yeah it's kind of a problem. I'm very, very unsold on explicit error handling compared to exceptions for practical program…
This article makes a lot of great points about the shortcomings of Go. I don’t think explicit error handling is one of them however. I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up. From a technical standpoint that isn’t necessarily a good argument, but from a pragmatic standpoint and decades of experience… well I will take expl…
They are just horrific gotos that any library can invoke against your code. They are pretty much never, ever handled correctly. And nearly always, after an exception is “handled”, the application is actually in an unknown state and cannot be reasoned about.
Even junior engineers have a trivial time debugging most go errors, while even experienced principles struggle with figuring out the true cause of a Java exception.
As a new joiner, some things have a "religious" feeling, like: the go gods have given us THE language and we must use it their way, without questioning too much.
I have the feeling other languages are less opinionated and this allows for more ergonomics and comfort when developing.
If I can't get at least ADTs and parametric typing, give me gradual like CL.
This article makes a lot of great points about the shortcomings of Go. I don’t think explicit error handling is one of them however. I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up. From a technical standpoint that isn’t necessarily a good argument, but from a pragmatic standpoint and decades of experience… well I will take expl…
No stacktraces and error wrapping forces you to not only invent unique error messages. You must also conceive a unique wrapping message at every call-site so that you can grep the error message and approximate a stacktrace.
The weird "return tuple" , which obviously just exists for errors because there is not a single other place where you can use tuples in the language, and the awkward variable initialization rules, make it so that you use the wrong `err` var at some point. E.g. if you want to reassign the result to an existing var, suddenly you have to declare `var err error`, and if `err` already exists then you have to reuse it.
There should be an enum type in go, or instead of the bizarre "return tuple" mechanics exclusive for errors, they should have added a better syntax sugar for errors like rust's `?` sugar. Instead we have something extremely tedious and quite error prone.
> it has a lot of build in opinions which protect you from yourself
It does have opinions, but too often they seem to be there to protect the language from being criticized. Sadly, this works, as marketing (lying) is an important factor towards making a PL popular in today's market.
This article makes a lot of great points about the shortcomings of Go. I don’t think explicit error handling is one of them however. I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up. From a technical standpoint that isn’t necessarily a good argument, but from a pragmatic standpoint and decades of experience… well I will take expl…
When I started trying to teach myself Rust, the error handling story fell apart on me very quick. Like as soon as I wanted to try and get sensible reporting in their, suddenly we were relieving libraries, adding shims and fighting mismatched types and every article was saying the same thing: haha yeah it's kind of a problem. I'm very, very unsold on explicit error handling compared to exceptions for practical program…