sagichmal

Gun is snake oil.

Don't filesystems already do this? Like, really really good?

I understand "singleton" as "only one exists" and "it exists in the global scope". That is, if I create one instance of something in my `int main()` that's not enough for it to be a singleton. That's important, because there's more than one way to enter your program. Notably, tests don't flow through your main entrypoint.

As dcow pointed out, it really doesn't work fine for testing, as it couples what should be isolated tests together, and prevents them from being executed concurrently.

Singletons are globals, aren't they?

Each of these things prevents isolated testing of dependent components. For that reason alone they are nonstarters.

> Unless you're doing something mathematical, where you can exhaustively test every input and output and ship something that's essentially close to the platonic ideal of the thing, you're going to need to update.

You only need to update dependencies that interact with things that change autonomously.

For the types of programs I write, that describes very few, sometimes none, of my dependencies.

Continuous updating of dependencies is valuable in some circumstances. Not all.

Many markets are strongly influenced by federal policy and have enormous lobbying groups, and capitalism by its nature harms vulnerable people. I don't see what makes housing unique in this sense.

I don't understand how anyone can view this as unfair. It's as basic as basic economics gets. It is obviously the case that downstream consumers of goods and services pay more than upstream suppliers. The initial investment is an enormous risk for the landlord, not something to just shrug off.

I guess if you view housing as somehow exempt from market dynamics, then this view holds water. I'm sympathetic to that view, honestly.

All evidence suggests the answer is actually "no".

I don't think you can generalize from that specific scenario to your broad claim.

It is not necessary to usurp famous city landmarks to offer affordable housing. Berlin is large and underdeveloped.

Zoning laws are not the thing restricting affordable housing supply, certainly not in Berlin and rarely elsewhere either.

Thanks for the reply. We have pretty compelling historical evidence that the market does not solve this problem.

What quotas are you referring to?

Is your claim that fewer regulations would result in a net increase in affordable housing stock?

This is... obviously not true?

Demand exists at a lower end of the market, where there is less incentive for suppliers. There is no affordable housing stock being created. Government exists for things precisely like this situation.

Tempelhofer is an enormous asset of the city and turning half of it into apartments would be a disgrace.

> Progressive taxes on investors can mitigate this and make home ownership more affordable

In Germany home ownership is not seen as strictly positive in the same way it is in the US for example. Many, perhaps even the majority, of Germans go their whole lives as renters.

Error handling is equally important to business logic. This is a core tenet of Go, an explicit design decision. If you don't agree with that statement, then you're gonna have a bad time.

The ? operator permits chaining, which obscures sad path control flow and makes code harder to reason about, not easier.

No, they offer observability as defined in your link.

The capabilities described in the post do indeed offer observability, not just monitoring.

At the moment, the capabilities of technology simply don't permit the level of... generic-ness? that vendors like OTel -- and customers really -- want. If you try to push everything through a single pipeline, as a single kind of data, you necessarily lock yourself out of most of the value you should be getting. You need a heterogeneous stack, with specific tools for specific purposes.

Opinions vary but my experience is that Prometheus-style metrics are by far the most important thing to invest in, and deliver the majority of the "observability value" to the broadest set of architectures. Tracing systems like Lightstep can be super useful, too, but to deliver value they need a lot more end-to-end integration effort, and the cost of setting it up can very very easily outweigh the benefits it provides.

I've come to believe that logs are a trap. Everyone understands them intuitively, so they feel comfortable using them for basically everything, without thinking very critically about the ramifications. And even when logs are structured, they have no substantive schema, so there's no backpressure, so to speak, on usage. So the signal/noise ratio almost immediately goes negative. And they just occupy enormous amounts of time and memory to manage, process, analyze, etc. Although I'm sure it's not a universal truth, I've found that everything you might normally think to log is actually much better served by in-process request tracing. In general that means maintaining the log events of the most recent N requests for all of a set of application-defined categories. This is basically a real-time view of a system, with history proportional to, I dunno, rarity? of the request class. You don't ship these anywhere, you ask the applications directly. It seems weird to describe but it's just vastly more efficient to manage, and equally if not more useful for debug and triage.

YMMV.

Parsing logs has a performance ceiling that locks you out of ~most of the value that good observability systems should be delivering.

> If there’s anything that’s an absolute must in my Observability to-do list, it’s getting org-wide acceptance of OpenTelemetry (OTel) for data-collection.

OpenTelemetry exists to allow CTOs to tick boxes on requirements checklists, and help to get the CNCF technology stack into the F500 space. The project is textbook design by committee, with seemingly infinite scope but very little acknowledgement of the actual technical constraints of the problem space. It claims it can solve a lot of problems, but I can say from first hand experience that it does not, and cannot, deliver on those claims. It's not good. Nobody with a choice should be using it.

> it’s just silly to confine quasi-generics to those 2 places

Why is it silly?

> the builtins are ad-hoc and half-assed

In what way are slices and maps half-assed?

> You may have already noticed that links to the package reference docs for the standard library on golang.org/pkg now redirect to their equivalents on pkg.go.dev, which is a better experience today and will continue to improve.

Facts not in evidence.

The "classic" golang.org documentation was simple, easy to search, and consistent across user agents. The pkg.go.dev documentation is... well, bluntly: strictly worse.

There are longstanding bugs in basically all user agents. The README for a module is unavoidably truncated by default and requires a click to expand. And the navigation panel on the left is only rendered beyond a certain browser width, and changes as you scroll -- in total, a UX disaster.

I'm so frustrated by these changes. It's one thing to update the look and feel of a site over time. I understand and that's fine. But this was clearly a design by committee, with no single coherent direction. The net effect ticks a lot of boxes but is just functionally worse.

Finalizers are not guaranteed to run. They're not ersatz destructors.

Nix is a prototype-grade implementation of a very narrowly useful model of computation.

> When you bring in technologies like Kafka to orchestrate this, you'll end up with a more reliable system that you can fix if something goes wrong.

It depends...

If your services are servicing typical user requests, and expect responses in O(<1s), then eventing architectures are exactly the opposite of what you want. Using message brokers (Kafka) as an ersatz network layer is the path to sadness -- you want backpressure, RPC semantics, etc.

https://programmingisterrible.com/post/162346490883/how-do-y...

If you're doing ETC/event semantics, the game is different. But very few orgs actually work that way.