herczegzsolt

I'd argue that anti-cheat is analogus to security-by-obscurity. It is basically a bad compromise to mitigate issues of a broken architecture.

Imagine that online banks would do login checks on client side, and you'd have to install anti-steal software before you can login. Would that be acceptable to reduce fraudalent transactions? Of course, there'll still be a signifcant amount of stolen funds, but it'd prevent most of your neighbors to login to your account.

Well, this is horrible design (and has basically happened with credit cards btw...) and you should address it at it's core, by bulding the architecture in a way that such fraudalent transactions are next-to impossible.

My point is: if cheating is so much of an issue, games should be architected in a way to avoid the ability of cheating from client-side at all, without additional monitoring required. Anti-cheat is a bad workaround to a core development problem, at the expense of the customer instead of developers.

This question sounds like you want to use Go and looking for justification :-).

To answer your question properly: I think programming language should be a financial choice for any company, and one of the highest cost factors is developer hours. All that i've described earlier is about optimising for developer hours.

If there's a nieche reason to prefer a language that may override all points i've described. For example, hardware support, availability of project-specific library, language preferences of customers, compliance requirements.

As for long term, i'd say 3-5 years is a tipping point, where maintaining PHP/Python becames more painful then just using Go. Probably a bit sooner for nodejs with the npm dependency hell. But i'd warn you about choosing Go due to planning your product to exist for more than 3-5 years. You'll almost certainly have multiple rewrites of your code before you get to a state where it actually lives for 5 years - if at all. Do yourself a favor and prototype in a quick language. Maybe even have your first versions out ugly and bodged. You'll have a chance to rewrite if and when you have customers and a working business model.

Lastly but most importantly, these are commercial considerations. For a non-commercial project, you should ignore these and optimize for developer-happiness instead. I like Go. I'd choose Go over PHP/Python/nodejs anytime as a developer. You should choose whatever you like the best. If you ask me, you should like Go the best :-)

I'd say yes. Anti-cheat and anti-crack has created far too many issues for me as a legitimate customer. I prefer paying for DRM-less content and opensource software, and i'd choose to pay them over commercially protected alternatives anytime.

Not entirely. It is a lot quicker to develop APIs in Go than to develop webpages. It is a very convenient choice and it's excellent compatibility promise makes it stable in long-term.

It'll still be slower to develop and iterate initially with Go, than with a bodged PHP or nodejs backend.

I'm somewhat comparing apples to oranges, because you could of course create very high quality, well-designed PHP or nodejs code. In that case it'll probably not be any quicker. The point is that you can quickly bodge in PHP a lot of stuff which you couldn't in Go. In my oppinion this is a benefit of Go in the long-term, but a signifcant overhead in the short term when you just need to get things done.

I'm just shutting down my startup, that was heavily relying on Gorilla-based web backends, but i've used django for larger projects as well.

In my personal experience, python is great for prototyping, but you'll be in growth pain, sometimes even as early as a hundred active users.

On the other hand, for me go is almost as productive as python. If i work in a team, i'd even say go is more productive. The simplicity and straightforwardness of go really saves a lot of trouble.

My personal preference of the two is Go, but i'd only use it if the code itself is important part for the product.

If the goal is to develop something for the web quickly, i'd use neither. They both have very basic UI features. Something like PHP or nodejs will give you results much quicker.

A big lesson for me was that quickly delivered questionable-quality software is usually more successful than great software with slightly slower development cycle. Go was not the right choice for the former.