151–160 of 508 posts
"With a Go function, if you ignore the returned error, you still get the result - most probably a null pointer." Well you should handle the error in the first place.
The language should make you handle the error and the compiler should refuse to compile your code until you have done so.
Earlier quoted context omitted.
Is there even a single go abstraction that doesn't leak it's guts everywhere?
There aren't any abstractions in any language or library that don't leak everything about what they are trying to hide as well as everything about their own implementation. That's just life. It's impossible to hide complexity. Whatever wraps one thing will be strictly more complex than the wrapped thing was.
(Yeah, it can’t compile easily distributable self contained binaries. It’s not (yet) designed for that.)
Not intending to start a language war, but your argument is basically the beaten wife claiming this is just standard treatment from husbands. This is my counterexample.
Can we just stop with the "Rust vs Go" shit? If you want me to take a critique of Go seriously these days, pick another language to compare it to. Any other language. And yeah, I'm aware that 5 years ago there were a ton of "Go vs Java" articles. I didn't think much of them then, either.
Author here - I apologize for pulling Rust into this, but for the life of me couldn't find any comparable language that solves those problems "the right way". I tried really hard. I knew a lot of people would instantly have that reaction, but I couldn't find another way to show that there is another way , short of pulling it out of thin air (which would've made for an even longer, less accessible article).
Earlier quoted context omitted.
Go goes out of its way to ensure you handle the error. You have to do something with that err return, otherwise it's a compile error. If you're just throwing it away without checking, we've gone from the mere mistakes everyday developers make to irresponsibility. There's a reason most go code is littered with "if err != nil" on nearly all function calls.
Go does absolutely nothing to ensure you handle the error. The only thing in Go source code that you see more often than the boiler plate "if err != nil" is "a, _ = foo()". It's all too easy to ignore an error in Go.
Where did you see that ? because that's not been my experience at all, and I've looked at a lot of Go code.
It's simply not true that Windows doesn't have "execute permissions" for files. It does:
https://docs.microsoft.com/en-us/windows/win32/fileio/file-s...
It's just that the people who wrote the go library couldn't be bothered to abstract this interface across all platforms.
If somehow we had a way of checking Golang's source and submit our desired changes...
Go and have a look at the issue the golang is discussing currently. Do you seriously think that everything can be fixed by a simple request?
Most of the time it wouldn't fit with the way Golang is going. It's not a critique of some bugs in Golang source code but the mentality and flow surrounding changes.
Do you except the author that submitted change overhauling the whole way Golang handles Unix vs Windows would be accepted?
I do not agree with the author, but that is fine. It's fine for me, understand it's not good for his use cases. Saying "duh, just submit your request" is stupid as it gets.
Here's an example of why Go's simplicity is complicated: Say I want to take a uuid.UUID [1] and use it as my id type for some database structs. At first, I just use naked UUIDs as the struct field types, but as my project grows, I find that it would be nice to give them all unique types to both avoid mixups and to make all my query functions clearer as to which id they are using. type DogId uuid.UUID type CatId uuid.…
I agree that the standard library database tooling is really clumsy in a lot of cases, but it's the library implementation at fault, not Go itself. Notably, contrary to your last sentence, you aren't troubling yourself with "weird Go semantics", you're troubling yourself with the semantics of the database stdlib.
It's still fundamentally caused by Go's shitty design choices.
encoding/json is at fault as well, which is also in the stdlib and a flagship library (basically part of the language - the maintainers wouldn't even extend its struct tag parsing to allow for required fields it's so fundamental!)
Proof that this issue affects JSON: https://play.golang.org/p/erfcSIe-Z7b
Here's an example of why Go's simplicity is complicated: Say I want to take a uuid.UUID [1] and use it as my id type for some database structs. At first, I just use naked UUIDs as the struct field types, but as my project grows, I find that it would be nice to give them all unique types to both avoid mixups and to make all my query functions clearer as to which id they are using. type DogId uuid.UUID type CatId uuid.…
A type alias binds a new name to a type. All of the type’s methods are available through the new name.
Proof that `type X Y` causes the issue: https://play.golang.org/p/erfcSIe-Z7b
> Computers, operating systems, networks are a hot mess. They're barely manageable, even if you know a decent amount about what you're doing. Nine out of ten software engineers agree: it's a miracle anything works at all. I like that he identified the real problem right at the start.
Here's an example of why Go's simplicity is complicated: Say I want to take a uuid.UUID [1] and use it as my id type for some database structs. At first, I just use naked UUIDs as the struct field types, but as my project grows, I find that it would be nice to give them all unique types to both avoid mixups and to make all my query functions clearer as to which id they are using. type DogId uuid.UUID type CatId uuid.…
Type aliases (type X = Y) are a niche feature and not meant for this use case. If you had done e.g. type X Y you would have had more success.
`type X Y` is still affected - you will 100% _not_ have more success :)
Proof (using JSON this time): https://play.golang.org/p/erfcSIe-Z7b