I remember being challenged to learn about the file system. All I was told was, use the man command. I knew CP/M, or better the East-German clone SCP, but that OS didn't know directories. I had to learn the concept from the man pages. There were no UNIX books in libraries or book stores. But it was fun, I managed to write a simple compression program doing run-length encoding on that system.

But generally I would agree that if you need to code parallel execution, channels are a good way to do it, because you can avoid race conditions if you share data only over channels. The biggest problem is that a lot of people don't understand, that channels with a buffer larger than 1 are a sign of problems in the architecture.

There is a type of parallel programming with workers for specific functions, that always leads to performance issues. The problem is you need to right-guess the distribution of work, when you have to define the amount of workers for a specific function. At least one go routine for one request is a much better approach than function-specific workers.

For the case here the server should call shutdown with SHUT_WR after sending the data and then drain the incoming data before closing the socket.

If Google has forgotten how to do Software, than the future doesn't look bright.

Nothing beats people knowing what they are doing and cleaning up behind them.

The first scenario is more likely, but you cannot exclude the second as well.

Sites of course could use the device public key extension of the WebAuthn protocol, to rely on more than a private key copied intransparently between devices, but I wonder, who will even know about it and actually use it. Google has stated they support the extension, but I cannot find a statement by Apple. A question whether DevPubKey is supported by Apple is unanswered on the Apple Developer Forums.

I have not seen a lot of comments that complained about the slower compile times. In my own experience it didn't really had an impact. But I agree the compiler should not become slower over time, so I appreciate the effort of the Go team to bring the compiler speed back.

I don't think that code readability is so much impacted. The square brackets work well. I find the angle brackets from C++ harder to read and there is the problem that >> is a token and cannot be used for two closing template angle brackets.

The increased complexity of the compiler is an issue, but cannot be avoided if you want to support Generics. But they took the time to make it right and as I stated it works for me.

I don't think that there is low adaption. Using type parameters visibly in a public API, breaks the API, which is the reason there are not a lot of uses in the standard library and with popular packages now. But this will change when maps and slices will be integrated in the standard library, which provide completely new APIs. Yesterday I found a library writing and reading parquet files, which used it quite extensively. But since I simply checked what libraries existed to assess how well the file format is supported, I cannot say much whether the use of type parameters by the library is useful.

OSS is basically exploiting a network effect that aggregates a lot of smaller contributions to a large one. Learning how to use a specific open-source software is the contribution the corporate free riders make.

The question is, how can the maintenance work be decentralized and distributed. Kubernetes changes the release manager for every version, so distributes the work over time. As long we rely on the single maintainer the results will not satisfy expectations. BTW a commercial company providing the support needs to solve the same problem.

The South had trouble to support their armies. Lee basically planned the Gettysburg campaign to live of the land. Soldiers were happy because they had enough to eat. A lot of soldiers lacked shoes.

Note also that as long as you have a single central database you don't need UUIDs. They are only needed if you have several processes creating objects without coordination.