281–290 of 310 posts
Earlier quoted context omitted.
fmt.Printf failures are un-actionable, so there's no reason to handle them
That's what the parent comment means, I think.
Actually, I'm reminded of certain errors I've seen along the lines of "exception raised while handing exception".
Earlier quoted context omitted.
With the default toolchain, Go has essentially two levels of visibility scoping: package-private (lower case) vs. exported (upper case) items, and module-internal vs. public packages (packages in the "internal" folder are not accessible from other modules). To make matters worse, all files in the same folder belong to the same package. (There are other toolchains out there that do things differently.) In larger proje…
Thank you for the in-depth response! Just to clarify my understanding, do you mean you want to encapsulate data structures within the same package (i.e. files in the same directory)? If so, I'm not clear why you can't break those up into a different package.
Earlier quoted context omitted.
Calling a linter thirdparty in Go is really disingenuous. Like you install go in your favourite IDE and it's batteries included. It's part of the standard set.
golangci-lint does not come batteries included. It is a third party library. Saying it's "part of the standard set" is really disingenuous
Earlier quoted context omitted.
>3. It's unclear who should add context to error messages is it the caller or callee? Usually it gets skipped, leading to useless error messages Why is that unclear? Let's say you are writting a db client package and a service around it. The package's db.Exec(query) method should return and error that will have an error text received from db if any AND\OR context from the package itself. Then in your service you add…
>> 6 > Not sure about "most" loggers, but I have no problem with zap. Popular, definetelly can be injected etc. That may be so, but a lot of libraries use a logger that isn't zap and isn't injectable, or the library doesn't expose a way to inject a logger even if the logger itself supports it. Plus, if you have 3 dependencies, you'll end up with 4 different logging libraries you need to worry about. In the end, you e…
Earlier quoted context omitted.
>> 6 > Not sure about "most" loggers, but I have no problem with zap. Popular, definetelly can be injected etc. That may be so, but a lot of libraries use a logger that isn't zap and isn't injectable, or the library doesn't expose a way to inject a logger even if the logger itself supports it. Plus, if you have 3 dependencies, you'll end up with 4 different logging libraries you need to worry about. In the end, you e…
I haven't seen a package that does not provide a way to inject a logger to be honest. I'd rather not use one or an least fork one if I'm out of options.
Earlier quoted context omitted.
Unfortunately, fmt.Errorf makes errors.Is/As useless. In fact, errors.Is is mostly useless in general, since very few Go libraries have any error types at all. You're usually stuck with parsing error messages if you actually want to handle errors programmatically, even for much of the standard library.
Uh? If you use `%w` in fmt.Errorf(), it should still work with .Is and .As?
This is equivalent to the problem of throwing new Exception("some message") or new RuntimeException("some message") in Java, to be fair. But this is more rarely done there in my experience, especially because people are more used to defining new exception types since the stdlib has many examples of that, unlike Go (which all returns `error` for all error types).
Earlier quoted context omitted.
> The number of reserved keywords is not a bad thing. I'm not saying reserved keywords are bad. I'm saying there's much more to learn about Java to learn programming, Go is limited with its' keywords and 'features', which often results in more LoC, but makes it super easy to get going, run into general programming problems like using a variable instead of a reference to it, etc. In Java, you spend much more time lear…
We should optimize for clear and concise code between experts. You’re going to be an expert for most of your career, and that’s when your time has the greatest value. A small learning curve is bad because you quickly run out of ways for tools to help you. I want to use the most powerful language I possibly can; the time investment pays off.
I want to learn programming before becoming an expert in the language. I feel like it's easier to do using Go. In Java you have to become a bit of both to be efficient.
Earlier quoted context omitted.
Go error messages are very much also tools for developers, if they are useful in any way.
true! of course.
More generally, user error messages and dev error messages are just fundamentally at odds, there is no way to have messages that are good for both cases. User error messages should explain what went wrong, and what they can do differently to workaround the issue (if anything). Dev error messages should explain what the code was doing when something went wrong, to help with figuring out what code needs to be modified.
Earlier quoted context omitted.
I mean, maybe - but there's a lot of examples of things being as popular as they are because google did them - gRPC, Protobuf, Kubernetes, Chromium. None of these things were technically bankrupt (including Go), but their adoption curve would not have been what they have been without Googles name on it. There's likely other OSS that's technically better, but did not have the network effects google-backed software had…
Go almost certainly would not have been as successful Without googles brand. But also, without its funding. Google has poured tens of millions of dollars in to go. all of the good qualities of go are due to its incredible funding, whether that’s tooling or the fact that three or four extremely experienced engineers were given years of time to design and implement it.
Assuredly not C++, nor Rust... No javascript, swift has become more complex apparently, not haskell... Not C... OCaml? No it has a weird syntax, French people and wanting to be different... Etc...
So no, Go has genuinely appreciable qualities that are not found anywhere else :o)
Earlier quoted context omitted.
Convention in no way prevents anything. Convention is simply that. People are free to not follow convention when nothing is enforcing it. You frequently see juniors, who may be brand new to the language, making mistakes with conventions. If I'm supposed to depend on the vagaries of some accepted standard that is only documented in text then it is less than useless in the real world
if we say a language "addresses" a given concern, is it necessary that this is accomplished in the compiler, and that the rules for that concern, whatever they are, are enforced at compile-time? (spoiler: no)
If the language "addresses" it by convention then it is not addressing it at a language level at all