alexvitkov
I rather appreciate that C and C++ don't have a default package manager that took over - yes, integrating libraries is a bit more difficult, but we also have a lot of small, self-contained libraries that just "do the thing" without pulling in a library that does colored text for logging, which pulls in tokio, which pulls in mio, which pulls in wasi, which pulls in serde, which is insane.
You're providing a library. That library has dependencies (although it shouldn't). You've written that library to work against a specific version of those dependencies. Vendoring these dependencies means shipping them with your library, and not relying on your user, or even worse, their package manager to provide said dependencies.
I don't know what industry you work in, who the regulatory body that certifies your code is, or what their procedures are, but if they're not certifying the "random library repos" that are part of your code, I pray I never have to interact with your code.
My point was not that running all that on one computer is a great idea...
Let's even say my numbers are wildly wrong, and they're processing 100x more transactions than what I claimed (which was already an overestimate). Tell me why you can't process 1600 transactions per second on one computer, especially for a country the size of the UK, where you would expect a ~15ms ping when talking to a server on the other side of the country.
If you're writing an ADAS system, and you have a "dependency tree" that needs to be "resolved" by a package manager, you should be fired immediately.
Any software that has lives riding on it, if it has dependencies, must be certified against a specific version of them, that should 100% of the time, without exceptions, must be vendored with the software.
> It is a guarantee of pain and ABI madness for anybody having to deal with the integration of your blob later on.
The exact opposite. Vendoring is the ONLY way to prevent the ABI madness of "v1.3.1 of libfoo exports libfoo_a but not libfoo_b, and v1.3.2 exports libfoo_b but not libfoo_c, and in 1.3.2 libfoo_b takes in a pointer to a struct that has a different layout."
If you MUST have libfoo (which you don't), you link your version of libfoo into your blob and you never expose any libfoo symbols in your library's blob.
My point was not that running all that on one computer is a great idea, just that 40,000 servers for a CRUD application is way past what should be considered reasonable.
But even that's fine. I like computers, you can have 40,000 of them if you want, even if the only reason they exist is some guy's job security. However, you're insane if the guy keeping them running doesn't work for you.
In the game development sphere, there's plenty of giant middleware packages for audio playback, physics engines, renderers, and other problems that are 1000x more complex and more useful than any given npm package, and yet I somehow don't have to "manage a dependency tree" and "resolve peer dependency conflicts" when using them.
If you need 40,000 servers to keep your business running (which you don't, your ~3-8 million weekly transactions can be processed on 1 computer, but whatever), hire people that will work on you, and whose paycheck depends on keeping those computers working, to keep those computers working.
Game theory arguments like "they wouldn't screw me over because other people won't want to do business with them" don't work when the other party is trying to maximize quarterly earnings, and their long-term thinking is in the order of ~2 years.
You'll find that programmers are a lot less prickly when you use AI to generate code, than say artists are, when you use it to generate pictures. You don't have to defend yourself, it's OK to use it to make cool things that you couldn't otherwise.
You should be aware though that even though it may "feel like magic" when just getting started, there's an upper limit to the complexity of what you can build with AI-generated code - it's very low quality and will start falling apart once you stack a lot of it. For the same reason I wouldn't recommend using it as a learning resource, if you really want to get into programming.
I proposed a solution for that in my original comment - you should be able to trivially bypass the capability system if you trust what you're running ($ yolo my_script.sh).
The existance of such a "yolo" command implies you're running in a shell with the "full capabilities" of your user, and that by default that shell launches child processes only a subset of those. "yolo" would then have to be a shell builtin, that overrides this behavior and launches the child process with the same caps as the shell itself.
But unless you can come up with a very detailed list of when it's acceptable "to lock people down and physically prevent them from harming themselves" and when it's not acceptable, and I don't think you have such a list, "sometimes" just means "whenever I, as the person writing the software judge", rendering it completely meaningless.
A working permission system would be objectively good. By that I mean one where a program called "image-editor" can only access "~/.config/image-editor", and files that you "File > Open". And if you want to bypass that and give it full permissions, it can be as simple as `$ yolo image-editor` or `# echo /usr/bin/image-editor >> /etc/yololist`.
A permission system that protects /usr/bin and /root, while /home/alex, where all my stuff is is a free-for-all, is bad. I know about chroot and Linux namespaces, and SELinux, and QEMU. None of these are an acceptable way to to day-to-day computing, if you actually want to get work done.
> We have to lock people down and physically prevent them from harming themselves.
You can apply this argument to literally anything, and taken to its logical conclusion, this is exactly what will happen.
Let me just give up on banking and the proprietary 2FA app that my job requires. Guess we're going homeless to protest Google, boys.
https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_A...
Given that it doesn't make money, it has zero value alive and at least epsilon value dead. Plus they don't need the links to work to collect metrics.
Whether or not Valve would want to encourage people to pay with crypto and expose their customer base to its volatility is another matter.
The vast majority of developers use these engines, so you would expect the vast majority of games to be stuff that's easy to make within those engines.
With how samey new games are, it's hard to argue that what we see comes close to the full design space of possible interesting games. That's partially developers copying games they've seen work and sell, but it's also developers making what is reasonably easy to make within Unity or Unreal with the resources they have.