Thank you for that. I absolutely love that this uses tantivy.
I was previously leaning torwards VictoriaMetrics and VictoriaTraces (I will need both) but I think that OpenObserve is even simpler. Later I found Gigapipe/qryn https://github.com/metrico/gigapipe
Does OpenObserve ships something to view traces and metrics? (it appears that Gigapipe does). Or am I supposed to just use Grafana? I want to cut down on moving pieces.
In my book the main problem with Helm charts is that every customization option needs to be implemented by the chart that way. There is no way for chart consumer to change anything the chart author did not allow to be changed. That leads to these overly complex and config heavy charts people publish - just to make sure everything is customizable for consumers.
I'd love something that works more like Kustomize but with other benefits of Helm charts (packaging, distribution via OCI, more straight forward value interpolation than overlays and patches, ...). So far none have ticked all my boxes.
Yeah too many times the Helm chart is barely less complex than writing all the manifests yourself because all the manifest options are still in the chart
fluxCD brings a really nice helm-controller that will allow to change manifests via a postRenderers stub while still allowing to use regular helm tooling against the cluster.
Yeah, but then it is yet another layer of configuration slapped on top of the previous layer of configuration. That can't be the best solution, can it? Same thing for piping helm template through Kustomize.
Yeah, this setup is both nice and insane. If you don't need much extra customization it's great. But I have a setup where I needed both postBuild and postRenderer's + actual kustomization layering and it was awful trying to figure out the order of execution to get the right final output.
In hindsight it would have been much faster to write the resources myself.
Kustomize can render Helm charts. It's "very basic" as in Kustomize will call the Helm binary to render the template, ingest it and apply patches.
I wrote a tool called "easykubenix" that works in a similar way, render the chart in a derivation, convert the YAML to JSON, import JSON into the Nix module structure and now you're free to override, remove or add anything you want :)
It's still very CLI deploy centric using kluctl as the deployment engine, but there's nothing preventing dumping the generated JSON (or YAML) manifests into a GitOps loop.
It doesn't make the public charts you consume any less horrible, but you don't have to care as much about them at least
But that is exactly what slog provides? The a unified interface that can be implemented by other logger libraries. Yes the Logger itself is not the interface, but the Handler it is backed by is.
> that’s stupid because people don’t typically use folders as if they were packages. Folders are typically used just to categorize things of similar meaning or naming or whatever you want
You might do that. That does not mean everyone organizes things like this.
What your chicken/egg example fails to realize is that things rarely just belong in one category. Chickens can be animals or food.
To me it just sounds like you are trying to write another language while using Go. Of course you will see problems. Just as you would see problems trying to write Go code when using Java.
In the end it comes down to this: if the language does not fit your mental model on how to do things, don't use it. But don't go around shitting on the language just because you are used to using folders differently than other people. Using a language also means learning and using the conventions of that language.
>You might do that. That does not mean everyone organizes things like this.
Most people do organize things arbitrarily based off of their own categorizations and opinions. In fact such an overwhelming majority of people who use operating systems do this that it's pretty much universal.
>What your chicken/egg example fails to realize is that things rarely just belong in one category. Chickens can be animals or food.
So what. I choose not to eat my chickens. So I Choose to categorize it in a way that makes sense to me. Why should I conform to your point of view? Why should I conform to golangs point of view? Why can't you and I choose how to do it?
>To me it just sounds like you are trying to write another language while using Go. Of course you will see problems. Just as you would see problems trying to write Go code when using Java.
No. I'm complaining about go. I think it's dumb. I'm not doing OOP here, I hate OOP. Go is waaay better. This is orthogonal to that problem.
>In the end it comes down to this: if the language does not fit your mental model on how to do things, don't use it. But don't go around shitting on the language just because you are used to using folders differently than other people. Using a language also means learning and using the conventions of that language.
Yeah that's how all complaints and criticisms are sidelined. "You don't like it, don't use it. Use something you like." Obviously.
I'm doing exactly that, while saying that go packages are a poor and horrible design decision.
I think a lot of people hated java, and found go and they think because go is so much better then java then that means go can do no wrong.
I don't think you realize there's stuff way better then go out there. But that's besides my point. What I use is separate from my point: Golang packages are poorly designed.
> I don't think you realize there's stuff way better then go out there.
Every language makes trade-offs. For you the trade-off Go makes is bad. I disagree. I like some languages better in certain parts, while I prefer Go's solution in other parts. It's all preference, there is almost never an objective "better" or "worse" like you seem to think.
Then you disagree with the majority of people. That's my point. This agree/disagree side lines the fact that people can be right or wrong. My claim is not only do you disagree, but you're wrong.
Majority of what people? Get off your high horse, your opinion is not a fact. Give me objective metrics to measure how "good" a language or language feature is, otherwise you are just wrong.
I'm looking forward to trying out your own perfect language that is objectively the best for any use case ever and no one can find any faults with it. Because surely such a language exists.
>Majority of what people? Get off your high horse, your opinion is not a fact.
Just look at reality and how people organize things everywhere. It's arbitrary. Adults are placed in offices and kids are placed in schools. Then on family trees kids and Adults are organized by dependency. How people organize things in the REAL world is AN arbitrary choice. But in GO you have NO CHOICE. It has to be by family tree. That is NOT an opinion. Everything I said is FACT.
The metric is basically the entire world and everything in it and how we fundamentally type (aka organize) things within it. But if you want to get more specific just look at every other programming language except go and look at how the entire world uses folders in operating systems. These are tools to allow people to arbitrarily organize things.
>I'm looking forward to trying out your own perfect language that is objectively the best for any use case ever and no one can find any faults with it. Because surely such a language exists.
Don't have one. I'm just commenting on what I hate about golang.
So a hand-wavy "look at the world bro" instead of actual metrics. Got it.
> I'm just commenting on what I hate about golang.
No you're not. You say Go (or a part of Go) is bad, which is vastly different. If you stuck to "I don't like it", you would not have gotten so much push back, but you insist in being right and everyone else is stupid and wrong.
Because metrics don’t exist. If the only way you can move forward and know something is because someone conducted some sort of statistical experiment with data analysis on it then I don’t even know how you get up in the morning. Do you need science to prove that when you jump off the bed there’s a floor that your feet will land on?
No you don’t. You’re not an idiot. It’s common sense that allows you to do this and it’s common sense that will allow you to see that the entire world works the way I said it does above. You don’t need science for this. At least most people don’t. Maybe you’re different and you need science to do an analysis for you before you open any door to make sure reality still exists behind it.
> No you're not. You say Go (or a part of Go) is bad, which is vastly different. If you stuck to "I don't like it", you would not have gotten so much push back, but you insist in being right and everyone else is stupid and wrong.
You’re right. Let me rephrase what I meant. I’m commenting about what is fundamentally terrible about golang and if you disagree then you're wrong because the overwhelming majority of the world would disagree.
