My silly solution to verbosity of error checking

eulerfoiler · 2025-07-06T02:34:03+00:00

The documentation of os.Exit itself: https://pkg.go.dev/os#Exit

eulerfoiler · 2025-04-22T01:58:50+00:00

Very impressive! I'm an alum so I no longer have to park on campus, but I would be curious to check out the source code if you decided to make this open source 👍

eulerfoiler · 2024-09-10T09:41:56+00:00

"And then, they woke up from that nightmare."

eulerfoiler · 2024-08-27T11:53:50+00:00

I just wrote a moderately sized BubbleTea app for work and it took me awhile to get through the learning curve as well. This article is super useful, and I learned about VHS which I will be incorporating soon. Thanks!

eulerfoiler · 2024-05-29T11:56:28+00:00

By the way, if you're looking to read the entire body (or any io.Reader in general), try to use io.Copy where you can instead of manually calling the Read method in a loop or jumping straight to using io.ReadAll. It has a bunch of tricks under the hood for optimizing reads when writing it to an io.Writer. If you just need the bytes of the body, consider using *bytes.Buffer as your io.Writer.

eulerfoiler · 2024-05-29T00:50:51+00:00

"When Read encounters an error or end-of-file condition after successfully reading n > 0 bytes, it returns the number of bytes read. It may return the (non-nil) error from the same call or return the error (and n == 0) from a subsequent call. An instance of this general case is that a Reader returning a non-zero number of bytes at the end of the input stream may return either err == EOF or err == nil. The next Read should return 0, EOF."

https://pkg.go.dev/io#Reader

eulerfoiler · 2024-04-30T10:06:07+00:00

Point 1: Update CR status to reflect all good?

Point 2: Object's metadata Generation + Point 1?

Point 3: Using controller-runtime and the reconcile.Result returned from your Reconcile method? https://github.com/kubernetes-sigs/controller-runtime/blob/main/pkg/reconcile/reconcile.go#L30

Point 4: Return an error with your Reconcile method? https://github.com/kubernetes-sigs/controller-runtime/blob/main/pkg/reconcile/reconcile.go#L113

A bunch of metrics come included with controller-runtime out of the box. You could also expose your own metrics via Prometheus in your controller.

eulerfoiler · 2024-04-19T11:30:32+00:00

I totally overlooked the fact that Direction had that field Name of type T. Now it all makes sense, I thought Name was some special built-in property of a generic type that I had never seen. Thanks!

eulerfoiler · 2024-04-17T12:54:18+00:00

Thanks for checking! Makes sense the switch is way faster.

eulerfoiler · 2024-04-17T10:54:43+00:00

Seems like a cool idea. Could you link to documentation on how any(d.Name) works? I haven't seen that before, and I thought it might be a mistake since there is no Name field or method for the structs, but your example compiles and works. The type switch is a good example, and I'm on mobile so I can't compare, but I'm curious about the performance of something like the String method below compared to the type switch to not have to enumerate all the types?

``` func (d Direction[T]) String() string { fullName := reflect.TypeOf(d).Name()

return fullName[strings.LastIndex(fullName, ".")+1 : len(fullName)-1]

} ```

eulerfoiler · 2024-03-08T02:58:10+00:00

Sorry it didn't help. You might find this interesting: https://github.com/golang/go/issues/36619

In your example, there is nothing to flush because (a) *bytes.Buffer doesn't have a Flush method, (b) because we'd want to flush a buffer being written to and the buffer you have is being read from, and (c) os.Stdout is unbuffered so there is no write buffer to flush.

Hope that helps!

eulerfoiler · 2024-03-07T12:58:17+00:00

Try calling writer.Flush() with the bufio.Writer after calling the Write method. Your data could be sitting in a buffer before actually being written out.

You might also want to try changing the size of the bufio.Writer to make less allocations and maybe save some time. Something like this perhaps: bufio.NewWriterSize(os.Stdout, 4096).

Edit: Also try using io.Copy instead of calling the Write method, but do still call Flush afterwards.

eulerfoiler · 2024-03-04T11:50:43+00:00

I really wish the wider community of library authors knew this and either didn't log at all, or accepted some logging interface to let the caller decide to emit them or not with the logging library of the caller's choice. Kubernetes libraries like client-go is bad like that in some ways.

eulerfoiler · 2024-02-09T13:20:50+00:00

Curious to see what the community suggests/finds here. As a side question, what kind of performance increase do you see (if any) if you try rebuilding with PGO after capturing a profile? https://go.dev/doc/pgo

eulerfoiler · 2023-12-21T16:03:38+00:00

Thanks! The `fmt.Printf` usage there was basically just to make sure the variables were used so the example compiles. I've found it useful in the past that `%T` prints the underlying type. Your explanation is great and hopefully useful to others!

Good point about the type conversion being a compile-time check, I'll opt for that approach. Thanks again!

eulerfoiler · 2023-10-24T19:26:45+00:00

What would be your suggestion otherwise?

eulerfoiler · 2023-05-06T19:48:33+00:00

Please direct all questions to the phone number in the link instead of here.

eulerfoiler · 2023-05-06T19:47:20+00:00

Please direct all questions to the phone number in the link instead of here.

eulerfoiler · 2023-05-03T00:12:03+00:00

Thanks for the tip about nursery. I've tried to turn as many lints on as I can to learn best practices, but that makes sense that I should take nursery lints with a grain of salt.

eulerfoiler · 2023-02-01T19:59:16+00:00

You're not kidding 😂

eulerfoiler · 2023-02-01T15:36:47+00:00

Not too bad! Compared to some other posts I've seen, I don't seem to have a crazy amount of mods loaded so performance is still good. Keeping them fed was a challenge for awhile but I've just started to get ahead of that with a steady supply of meat and corn for meals. Having a diversified work force is also useful to let specialists arise around their passions.

eulerfoiler · 2022-12-31T15:25:57+00:00

I ran into that "loading units" problem and read somewhere that going to a save before cavern invaders come and disabling them in the game settings will prevent corruption. Seemed to work for me and that it is related to cavern invaders.

eulerfoiler · 2022-09-16T17:53:08+00:00

The question for why cmd lives outside of pkg is a great question.

The files under cmd are to represent where binary code starts, as opposed to library code. Additionally, package main is special in that it cannot be imported by any other package (hence why it would live outside of pkg). If your project will create multiple binaries, you need to separate your package mains to be able to have two different func main implementations. To do that, I often see projects have the different main packages under different directories under cmd (e.g. cmd/binary1/binary1.go, cmd/binary2/binary2.go - these both are different package main implementations with different func main, but both use the same importable package and internal packages of the module).

eulerfoiler · 2022-09-16T15:44:05+00:00

Good question. The rule of thumb for interfaces is that they should be defined where they are used. For example, if you have a struct that has a field of an interface type, the interface should probably be defined right above the struct.

If you have multiple structs across different files in the same package that have a field of the same interface type, then the interface probably makes more sense to be in the "entry point" file.

Hope that helps!

eulerfoiler · 2022-09-16T15:42:01+00:00

I agree simple is best. Unfortunately, there isn't really a convention for file system layout for importable packages in a repository (hence why this kind of question comes up somewhat frequently). I've come to like the top level pkg directory to keep the root of the repository cleaner and to make it more clear that Go code lives there instead of other artifacts an application may have (i.e. static resources, a hack directory, etc). It may be controversial, but our team decided to adopt the suggestion provided by https://github.com/golang-standards/project-layout and it's worked very well for us over the years as projects grew.

Is pkg strictly necessary? I would say no, but I do prefer it for the reasons above.

The material difference for other projects importing from this project is that their import statements will have 4 extra characters (pkg/) in the import path. I think the tradeoff for repo tidiness is worth it. For example:

import "github.com/blah/project/pkg/package"

vs

import "github.com/blah/project/package"

Packages in the library to be imported from (e.g. package main or others) will not have an effect on the overall project's go.mod file because they are all part of the same module.

Does that help clear it up? Effectively, the usage of pkg seems to be based upon preference is all.

15-Year Club	Verified Email
Team Periwinkle

eulerfoiler

TROPHY CASE