sagichmal

> The benefit is that I don't have to write these boring, but necessary pieces

The component graph of your application isn't boring, it's the most important part of the thing, and the starting point for anyone trying to build a mental model of the thing. It should be front and center, never hidden away behind generated code.

Sure, but you don't need a framework or DSL for this in Go.

The things you describe are pretty strongly understood as antipatterns in Go.

Freedom of speech is a means, not an end. It's a tool that we can use to shape society as we see fit.

This is too naive. Should a 9-year-old black girl be forced to endure racial epithets yelled at her as she enters her school on a daily basis because free speech is so sacrosanct it outweighs the abuse? Obviously not. The truth is in the gray -- free speech isn't an absolute.

And I agree with that framing, too.

It's fine that morality is subjective. Objectivity isn't a requirement for ethical action -- I don't need to write a formal proof to ban a white ethnostate nationalist from my web forum.

> What about Trump/Russia collusion?

You mean the thing that several people were tried and found guilty of?

This is an anachronistic view, and empirically ineffective.

White ethno-nationalists are not "right leaning".

This is a ludicrous conclusion to draw.

It is both ludicrous and offensive to suggest that the things we're seeing now are in any way a consequence of curtailing hateful speech.

I hope your cynicism is a force for good in your life.

Wasm is structurally similar to those things, yes, but is so much faster that it is actually categorically different.

A transaction which is partition-tolerant in the way you're describing requires stronger semantics than mere client acknowledgement, it requires all participants to engage in the consensus protocol. Unless your application joins the message broker's topology as an active member -- some systems do work this way, like Zookeeper -- it can still suffer message loss.

But even if it does join, that's still not sufficient, because these systems can become unavailable during partitions, and that is definitionally incompatible with "exactly once".

So we're just playing semantic games at this point, using different definitions of terms. The definition of "exactly once" you're using isn't the formal definition.

Even in the face of network partitions?

> You can't,

I don't need to.

> The baseline is not humans. We are one part of the universe not the center. Logic is the baseline.

Logic is not the baseline of human constructs.

> monolith vs. microservices? Which is actually better? ... the resulting non-answer people come up with is: "Depends on your use-case."

But that's the truth of the matter. _Neither_ is "actually better" without qualifications.

Formalism as you describe it is an abstraction that we invented to help us model stuff. It's not more true, or more accurate, or strictly better than any other abstraction.

The fact that design and systems and law and economics and philosophy and etc. etc. are ultimately squishy and informal is actually a reflection of the truth. Down there at the bottom of everything? It's humans. Subjective, emotional, informal humans. That's the baseline. Use formalism where it helps, absolutely, but don't trick yourself into believing it's a better way of being, of doing. It's not.

> Passing pointers to shared memory is highly unsafe in Go. While the Rust borrow checker will prevent all data races, there's nothing like that wrt. Go

Passing pointers to shared memory is the foundation of a huge number of idiomatic, performant, and productive design patterns and architectures. There exist a number of conventions and tools, like the race detector, which reduce the risks of data races to entirely reasonable levels.

Passing pointers over channels doesn't necessarily mean you're sharing memory, you could be passing ownership. Pointer or value are both equally idiomatic.

I read everything completely differently.

The thing that strikes me about this issue is how unhelpful and, well, rude the author is. Terse, minimum viable answers to questions, no contextual detail even when it is obviously needed, and an air of expectation, as if the maintainers owe him a solution.

Go makes concurrency about as tricky as a reasonably complex data structure. can you still write a bug? Of course. Is it so tricky that bugs are inevitable, or even common? Absolutely not.

You underestimate how common this use case is. It motivates the Go language, which is much more widely used than Rust.

> Shared-memory concurrency is pretty much always buggy, IME, even if your team thinks they're experts.

Writing bug-free shared memory concurrency programs with Go is trivial. Your opinion is based on outdated information.

Not all code is knowledge, in this sense. And sometimes repeating knowledge is better, on balance, than unifying it somewhere, when you consider the added costs of coupling, of reification, and of abstraction liability.

Refactoring repeated code is toil, but cognitively trivial. Refactoring a bad or leaky abstraction can be fiendishly difficult. I'll take the toil any day.