Imperative version can fill more dynamic use cases, like spinning up entire servers in response to something (eg user wants to create a game server at the click of a button).
Not something you can easily do with the declarative version.
I enforce formatters wherever possible after working on codebases with 20+ years of people imposing their own unique opinion on where spaces and braces should go. Worse, arguing about what the spacing should be, and making noisy diffs because people change previous peoples styling.
The formatter has no opinion. It follows rules. It doesn't work perfectly everywhere. It works enough. I would argue caring about exact bespoke spacing of all code is the perfectionism you mention.
There is no reason why each of us can't have the formatted according to one's taste (=what works best), instead of this "communism". It's just a matter of IDE support that is lacking.
The IDE should apply user formatting preferences upon reading in the file, and apply the std formatting while writing it (with the aim of having diffs work well). That would make good use of auto-formatters.
Okay, but the IDE support is lacking so that workaround isn't available. If you want that functionality instead you'll have to (1) add it to your IDE (2) force your team to use your favourite IDE instead of their favourite IDE. Insisting on some alternate reality where you have different tools than you actually have isn't helpful
I think it's bad without the rest of the supporting toolchain but it's not axiomatically bad. There are languages with structured editors (e.g. https://hazel.org/), people can use different tabstop settings and even just different editor colours and wrapping settings and I think we can agree that doesn't doesn't hurt anything. Enforcing an automatic formatter is more or less identical to this anyway: you can write your code using whatever style you want but what ends up in the repo is equivalent to the compiler but not identical to what you wrote. You can imagine running your own local formatter on the code before you edit it and running the global formatter afterwards and an observer being unable to tell that that's happened.
A lot of the work I do recently has been using devcontainers in VSCode [1]. They even have a Rust sample one. I feel like this would provide at least a little bit of protection against this kind of attack if you do not mount any imporant stuff into the container.
What makes you think that will happen? A lot of young people I know seem to understand just as little about computers as the older ones, on average.
Younger people use technology a lot, but what is being used tends to require much less understanding of any of the underlying tech. The level of abstraction is a lot higher now.
So true. They laugh at me 'cuz I know nothing about the latest app. I laugh at them because they have no idea how their computer works.
How many times do I advise: "Just unplug it and plug it back in."
P.S. for non-digital electronics, the cold reset doesn't work.
P.P.S. My skill at writing programs took an enormous discontinuous leap forward when I learned how transistors worked, how to wire up a transistor to make a flip flop, and how to hook up flip flops to make registers, adders, etc.
Any sufficiently advanced technology is indistinguishable from magic is generally used to talk about how it works for a less developed civilization meeting a more developed one, but perhaps it also pertains to the non technicians in the magic civilization.
At a certain point of specialization and advancement it no longer seems productive use of your time to try to understand it, leading to large portions of the population who view the technicians holding things together as inscrutable magicians.
It'll happen incrementally. Each time the lawyer ruling class does something bad, like build a website that doesn't work, they'll need to give us a little more power in order to save them. Then after a long enough timeline, we'll win, and legal code will be executable.
I’m not sure it’ll work out this way because a lawyer can become a coder much easier than a coder can become a lawyer. Then again, lawyers are notoriously allergic to all-things-technology, so who knows.
These restrictions are only for the SES sandbox mode. You fill in a form to get out of sandbox mode and then you can send many more per day (still only 14/second or so).
You only verify addresses you want to send from (for testing you might verify one to try sending to as per the sandbox rules). You wouldn't get customers to verify their addresses here, as that would let you send email on their behalf.
All very good info that as far as I know is all pretty unique to SES regarding the default/sandbox vs the upgraded production capabilities. The set up makes a lot of sense to prevent abuse and it works just fine out of the box for dev purposes. The production version also operates way more how you'd actually expect an email service to work.
All that said, I don't know of any other services that have this "production" upgrade that is needed other than maybe just the general service limits (which have always seemed more of a "protect you from yourself" situation) so it can be a touch confusing.
Sandbox mode is also great for low-volume internal mail like notifications from cron.
My guess is that the main argument for sandbox mode is that it requires you to explicitly say you don’t spam and will handle reports, giving them carte blanche to yank your account if you do. Given how slimy email marketing is I suspect someone at AWS didn’t want to deal with people lying to their support people all of the time.
And once you are out of sandbox mode, it scales pretty well. We regularly send millions of mails in 24hr periods. Some gotchas come in when you need to set up DKIM/etc and other providers may need to handle mail for the same domain.
