It's a decent one for "locks on an apartment building that someone else owns."

But no, purchasing a house ought not include by default "a set of locks that you must work around, permission-wise."

Y’know, for security.

And then, do computers.

Apples and oranges here, for this point.

I can't say whether this trend would continue, but the answer to your question today is "yes".

And those uses which fall short of the new threshold, e.g. hobbyist SBCs, slowly fall away.

Raspberry PI is the defacto standard for SBCs. Almost all the other SBCs had significant problems usually around software support and also third party support e.g. Hats, cases etc.

There was also something about needing to back out if any of the reads fails to acquire, which also sounds nasty.

Ah, interesting, so wfm does both the wait and the acquire!

When using eventfd it is indeed annoying having to both poll and later read to disarm the object (there are epoll tricks that can be used but are not generalizable).

The signal+wait is also a primitive that it is hard to implement atomically on posix.

That would have a number of advantages, come to think of it. For starters, install size could be much lower, piracy would be a non-issue, and there would be no need to worry about cross-platform development concerns.

However, Teardown is in the set of games where it just barely works and only if all the stars and the moon align. I'd characterize it as something like, cloud gaming spends 100% of the margin, so if anything, anything goes wrong, it doesn't work very well.

(Plus, as excited as the companies are about locking us into subscriptions rather than purchases that we own, when it comes time to actually pay for the service they are delivering they sure do like to skimp, because it turns out it's kind of expensive to dedicate the equivalent of a high-end gaming console per person. Most stuff that lives in the cloud, a single user averages using a vanishing fraction of a machine over time, not consuming entire servers at a time. Which doesn't pair well with "you spent 100% of the margin just getting cloud gaming to work at all".)

With that being said, its trivial to bypass with tools like: https://github.com/keylase/nvidia-patch

Regardless, this does throw a spanner in the works for a video based game streaming solution for P2P multiplayer.

The reason it feels like a kludge is that "comments" are normally understood to be non-impactful. Is a source transformation that removes all comments valid? If comments have no impact per the spec, yes. But that's not the case here.

In practice comments in go are defined to be able to carry semantic meaning extensibly. Whether they're safe to ignore depends on what meaning is given to the directives, e.g. conditional compilation directives.

It's certainly done in many places. JsDoc is the biggest example I can think of. But they're all walking the line of "this doesn't have an impact, except when it does".

It being done by the language owners just makes them the ones walking the line.

In practice, the Go language developers carved syntax out of comments, so that a comment is "anything that starts with //, unless the next characters are go:"

If it would make you happier you can imagine this is part of the spec. It wouldn't change much if it was.

Why would millions of programs becoming out of date with the spec make me happy. There is value in the language maintainers and go programmers talking about the same object. I don't disagree that '// ' is standard Go style (and more readable), but it would break all the code that uses //comments /// ////.

I DO agree that it wouldn't change much if by 'it' you mean the go language and it's tooling, a proper spec does prevent arbitrary change. But it should have been added at least 5 years ago.

There was no such statement. "In practice" clearly indicates the contrary about it being "strict" and certainly encompasses the possibility that it only developed over time.

https://go.dev/blog/inliner#example-fixing-api-design-flaws

So these comments carry more weight than how those comment annotations might be consumed by optional tools for other languages.

For most of the listed examples, I think the corresponding C annotation would have been "[[deprecated]]", which has been added to the syntax as of C23.

That's why you find it in the comments. That is where tools have found a place to add their own syntax without breaking the Go code.

Absolutely you can do the same in Java. It exists to the exact same degree as it does in Go. I expect it isn't done as often in the Java world because it is much harder to parse Java code so the tools don't get built.

Things like "//go:embed" and "//go:build" very much do change the semantics of source code.

The comments above 'import "C"' containing C function definitions and imports change the compilation of go source code.

The "//go" comments contain a mix of ones that must be respected to compile, to being optional, to being entirely ignorable (like generate and fix).

When you take the source code as a whole they do, but the Go parts are unchanged. The Go spec says nothing about //go:embed, or //go:build. These are not Go features. What you are looking at is another programming language that has been added by a particular tool, using Go comments as the gateway to supporting non-standard syntax inline.

> The "//go" comments contain a mix of ones that must be respected to compile

That is true, but in using it you've accepted that you are no longer writing Go. In fact, with respect to your talk of C, "Cgo is not Go" is one of the most oft-repeated lines seen in the Go community. It's not just a silly catchphrase. It is the technical reality. Cgo is literally a different programming language, much like how Objective-C is not C despite supporting everything C does.

So the go stdlib also isn't "the go programming language"? The 'golang.org/x' repositories aren't standard go?

I feel like you're no-true-scottsmanning this into a meaningless definition where the spec defines Go, but all Go code in existence is not actually Go code, it's a different programming language which everyone happens to call Go and think of as Go.

Like, sure, redefine Go like that if you want, but I don't think anyone else in practice thinks "Ah, yes, the go stdlib isn't actually written in Go", so you'll be off by yourself with that definition.

Which standard library? There isn't just one. tinygo's standard library, for example, isn't the same as gc's. They are, in most cases, API compatible, but there are some packages not shared and they are completely different codebases. A standard library is a distribution concern, not a language concern.

Maybe you're caught up thinking in some other kind of language that only has one distribution and trying to apply that misaligned logic to programming at large?

> I feel like you're no-true-scottsmanning this into a meaningless definition

It's not, though. It is actually something you have to think about in the real world. A 100% spec-complaint Go compiler can be completely unable to use gc's standard library code as it contains additional language constructs that are bound to gc specifically.

> I don't think anyone else in practice thinks "Ah, yes, the go stdlib isn't actually written in Go"

Again, its not clear which standard library you are referring to, but if we assume gc's it is mostly written in Go, but it contains extensions that are not Go. If you say that it was written in Go casually, people will know what you mean, but technically, no, it isn't written in Go. At least no more than an Objective-C program is written in C.

But, unlike Objective-C, the extensions are added in such a way that they remain valid Go syntactically. That means you can use, say, a Go language server on gc's standard library without it blowing up on the extensions. It gives the advantage of a new language, but without having to build new language tools.

This is not inlining in the compiler. It's a directive to a source transformation (refactoring) tool. So yes, this has no impact on the code. It will do things if you run `go fix` on your codebase, otherwise it won't.

The knife manufacturer isn't obligated to sell to you in either case, I'd expect them not to cut ties with you in the self defence scenario. But it is their choice.

1. Found out you used their knives to go murdering

2. Sells knives in a fashion where it's possible for them to prevent you from buying their knives (i.e. direct to consumer sales)

Would almost certainly not "be more than happy to continue to sell to you". Even if we ignore the fact that most people are simply against assisting in murders (which by itself is a sufficient justification in most companies), the bad PR (see the "found out" and "direct to consumer" part) would make you a hugely unprofitable customer.

> the bad PR (see the "found out" and "direct to consumer" part) would make you a hugely unprofitable customer.

That... Doesn't happen.

Boycotts by people who weren't going to buy your product anyway are immaterial to business. The inevitable lawsuits are costly, but are generally thought of as good publicity, because they keep the business name in the news.

People who buy (and make) firearms are... pretty close to the exact opposite.

Goalposts moved.

Where either it's a computer program (website) that knows nothing about you, or cutco.

If you think you wouldn't find a cutco representative to sell to you, you're on some good reality-altering drugs.

There will always be some company willing to sell to even the worst person, in any product category.

The response that companies have to boycotts, and the results of the boycotts themselves, are fractally chaotic at best.

But even most nominally socially-aware companies are reactive, rather than proactive.

It's about how we think they will act.

Especially when it comes to sales to the US military, I have no expectations about how companies will act.

Hell, just look at how many companies willingly helped China with their Great Firewall.

What I mean is that you _did_ judge them by a standard used for weapons manufacturers. How you react to their actions _is_ your judgement.

But perhaps that is the standard we should use. Weapons manufacturing is a well regulated industry after all. Export controls, dual-use technology restrictions, if it has applications for warfare it should be appropriately restricted.

I think any of these companies will attempt to get away with whatever the fuck they can.

That has fuckall to do with your rhetorical question of:

> That's the standard we should judge them by?