They're charging you for orchestration, log storage, artifact storage, continued development of the runner binary itself and features available to self-hosted machines. What would your own machine do without the runner and service it connects to?
Agree. We're using C# in the backend for an MMO, and while I would still like _more_ control over the memory management, there's a ton of options for dropping down to a low level and avoiding the GC.
Stuff like ReadOnlySpan and IMemoryOwner are awesome to have as built-in language concepts.
> On top of that, most infra tooling—Grafana, Prometheus, Kubernetes, Terraform—is written in Go, so choosing Go for the backend comes with a ton of advantages over C#.
Not once have I ever had to interact with these technologies in a way that would benefit from my application using the same language. The language they are written in is irrelevant.
>Not once have I ever had to interact with these technologies in a way that would benefit from my application using the same language.
You haven't had to or refuse to? I've interacted with plenty of C# teams in my career and getting them to step outside the box to solve an actual technical problem in a reasonable way is _painful_ for this very reason.
They'd rather set up a meeting or hire more consultants and stonewall a project for over a year.
Most programmers can learn and pick up C# in like a day, but Windows-based developers seem to have a lot of trouble going the other way.
As a counterpoint, I have many times had to interact with the those technologies, and thus been able to use their source code as packages and/or learn their source code techniques which I have then used in my own Go programs.
What does that prove? it proves that no single developer's anecdotal evidence can be used to validate a broad-brushed claim like "The language they are written in is irrelevant."
I run a monitoring startup (StackScout) where I'm rewriting the main API from PHP to C#, but the actual agent you install on your servers (so typical systems programming) is and will stay written in Go. It's ok to not have all your tech stack in a single language.
It's HTTPS. Not only are you getting checksumming from TCP, but any block that had bitflips would fail TLS decryption and would fail the entire transfer. You're not going to see silent corruption in transit.
TCP implementations are an abstraction that work 99.99% of the time, but are still vulnerable to two generals when you look close. TCP is implemented in the kernel with a buffer, the kernel responds with ACKs before an application reads the data.
There is no guarantee that the application reads from that buffer (e.g. the process could crash), so the client on the other end believes that the application has received the message even though it hasn't.
The kernel is handling at-least-once delivery with the network boundary and turning it into at-most-once with the process boundary.
What makes you think the 2GP is relevant here? The 2GP has to do with coordination and consensus, not exactly-once delivery.
> TCP is implemented in the kernel with a buffer, the kernel responds with ACKs before an application reads the data.
True. Why do you think that matters?
> There is no guarantee that the application reads from that buffer
So? What does that have to do with exactly-once delivery? Even if the application does read the data, there's no guarantee that it does anything with it afterwards.
> The kernel is handling at-least-once delivery with the network boundary and turning it into at-most-once with the process boundary.
OK, if that's how you're defining your terms, I agree that you cannot have exactly-once delivery. But that makes it a vacuous observation. You can always get at-most-once delivery by disconnecting the network entirely. That provides a 100% guarantee that no message will be delivered more than once (because no message will ever be delivered at all). But that doesn't seem very useful.
You are in control. You can disable secure boot, you can install your own keys, you don't have to boot windows, you don't have to play games that demand invasive anti-cheat. Vote with your wallet.
Relying on the community to police cheaters is not an effective strategy for online skill-based matchmaking games. There's a reason game companies spend money and effort on anti-cheat and it's not because they're ignoring cheaper alternatives.
Wow how did I not think of that, surely the pattern of services getting worse to extract more money from users is due to someone saying a dirty word on the internet.
I would highly recommend getting a drone simulator off Steam. You can practice the controls and drill them into your fingertips during times when you can't fly the real thing (battery recharging, night time, weather, ...). Most advanced radios allow you to hook them up to the computer so you can fly with the exact same inputs, but a console controller is also acceptable.
