realharo

Definitely needs to be solved where it exists, but there are many places in the world that don't have this problem.

This is exactly the point made in this 2010 article that's probably one of the things I link to most often in online discussions.

https://whatheco.de/2010/12/07/function-hell/

Also, the real problem with code on the right in OP is all the state mutations made to the arguments passed into the functions.

Not too familiar with golang, but this really could use some sort of builder pattern or something, if you're going to mutate the object. Or a more functional style with just a pure function mapping an input "order" to output "toppings", etc.

There are plenty of ways to make the bad design on the right better without stuffing everything into a single function, so the whole premise is a bit of a false dichotomy.

https://github.com/GoogleContainerTools/distroless

That sounds like spending a lot of extra effort just to avoid a little up-front effort.

it represents decentralization and digital democracy. No more concerns about privacy breaches, identity exposures, or data leaks

It doesn't, and it does absolutely nothing to address those issues.

E2EE is mainly a client-side matter, makes no difference how "centralized" or not the server part it.

And ironically Python (with Pygame which they also used) is a terrible choice for this kind of game - they ended up making a desktop game that the user would have to download. Not playable on the web, not usable for a mobile app.

More interestingly, if decisions like these are going to be made even more based on memes and random blogposts, that creates some worrying incentives for even more spambots. Influence the training data, and you're influencing the decision making. It kind of works like that for people too, but with AI, it's supercharged to the next level.

Future software is going to be written by AI

Of course, if you look far enough into the future. Look far enough and the whole concept of "software" itself could become obsolete.

The main disagreements are about how close that future is (years, decades, etc), and whether just expanding upon current approaches to AI will get us there, or we will need a completely different approach.

This is also the kind of task you would expect it to be great at - tutorial-friendly project for which there are tons of examples and articles written online, that guide the reader from start to finish.

The kind of thing you would get a YouTube tutorial for in 2016 with title like "make [thing] in 10 minutes!". (see https://www.google.com/search?q=flappy+bird+in+10+minutes)

Other things like that include TODO lists (which is even used as a task for framework comparisons), tile-based platformer games, wordle clones, flappy bird clones, chess (including online play and basic bots), URL shorteners, Twitter clones, blogging CMSs, recipe books and other basic CRUD apps.

I wasn't able to find a list of tasks in the linked paper, but based on the gomoku one, I suspect a lot of it will be things like these.

I guess you wouldn't. Use a different protocol, one that supports the security you need.

It would be fine if the footage was end-to-end encrypted, meaning you need to transfer the encryption/decryption keys from device (e.g. a phone) to camera, and then manually between all devices that should have access to the decrypted footage.

Camera would only ever send out encrypted footage, and thus it would be insufficient to have access to the cloud account if you want to view the footage - you would need both access to the account (to obtain the encrypted data) and the decryption key (to actually decrypt it). The decryption key must never reach any 3rd party servers and can only be manually transferred between devices that should have access.

There are still possible attack vectors, like malicious firmware updates, or the viewer client app updates, but those are very difficult to exploit, and pretty much exist in most "secure" software today (including from companies like Google, Apple, Meta, etc.). They could be mitigated by hardware design (do the encryption in hardware, camera's software never has access to decrypted footage) and open source viewer clients that the user controls, but I would consider a camera sufficiently secure (for non-sensitive locations) without those.

Are Go-style channels different from what Tokio provides? https://tokio.rs/tokio/tutorial/channels

It's just inherently suspicious, because there is no valid technical reason to do it that way (things just end up being more complicated, more expensive, etc., for no benefit, not to mention the brand damage), unless you have some future plans for it that will involve crypto/NFT crap. The fact that MrBeast has a history with NFTs also doesn't help.

Or course it's still pure speculation.

Have they explained why they chose to use it in some plausible way?