Is this conclusion purely theoretical, or based on any experience at all?
Because anecdotally, the cops that interacted with me and people around me where completely uninterested in doing any kind of work, no matter how easy it was.
Our field is getting closer and closer to architecture and medicine now. We've tech like this we can come out of the fiddling age and deep dive into a serious engineering culture.
Quick question: how do you prevent persisting the effect of a DOS attack on those systems?
> Our field is getting closer and closer to architecture and medicine now. We've tech like this we can come out of the fiddling age and deep dive into a serious engineering culture.
This comment reads like ml-generated nonsense. Architecture is summed up as subjective opinions bounded by regulatory constraints, and medicine is still empirical knowledge validated through experiments. None of these fields have even a passing resemblance with engineering.
> That's why I said architecture and medicine and not rocket science.
You conflated architecture and medicine to a builduo to "serious engineering culture". There is no way around it: it's nonsense. Even though they are highly specialized fields, neither architecture not medicine has anything to do with the basic principles of engineering. It's just nonsensical word soup.
Medicine has incredibly rigorous engineering processes; if anything I'd say the software world at large has a thing or two to learn from medicine (particularly class II+ devices) about building robust, long lasting software that you know works the way you designed it to
> Medicine has incredibly rigorous engineering processes (...)
You're confusing with mechanical engineering applied to medical devices with medicine.
It's like claiming bakeries have incredible rigorous engineering processes just because mechanical and industrial engineers design devices and automate processes.
Not the same thing, is it?
> See: ISO13485, IEC60601, QMS, etc
You're just pointing to standards that engineers working on specialized devices need to comply. One covers quality assurance and the other is focused on specialized electrical equipment.
That's true, those are merely popular examples of how engineering is done in med device, and not specific to the software side, though there are standards and guidance documents for specific fields. I didn't want to get too off in the weeds. But to be a 13485-compliant device developer, you need to have a competent requirements-driven, verified and validated development cycle, release process, and a complete design history with traceability all throughout, so you can immediately link problems to the actual components that caused them.
As an analogy, it takes the bill-of-materials approach done by popular package managers and makes it a whole lot more rigorous.
I do this, and it's a little onerous, but it's mostly just half-decent engineering. E.g. every commit has a ticket; every ticket has clear test criteria and a requirement to link back to (also a ticket, sometimes), every PR has a reviewer, every PR is tested by someone, every release knows what commits it has in it. Most of it can be done by Jira (or similar) and Git, and a fairly normal process. Not a Amazon-style 1000 changes a day sort of process, but still.
I find that it’s more popular to pontificate about what it means for software to engineered to a high standard. That sorta rest on ignoring the fact there are localized fields where we know how to do it. People want to talk hypotheticals rather than go see how we do it.
We know how, it’s just slow, expensive and the tooling isn’t some fantasy perfect environment where safety and effectiveness is already built in and developers just do the business logic.
Do we know how? When I look at things like ISO 26262 I see an attempt to use poor tools to cobble together something barely adequate with the expenditure of an enormous amount of human labour. The results are nothing to write home about.
Neither Architecture[1] nor medicine[2] are engineering disciplines, so I don't really see how getting close to them gets us to an engineering culture.
[1] Which is a form of art. Go look at a school of architecture at a university it will be in the Art faculty.
[2] Which is an applied science like engineering but is not an engineering discipline.
Fallout 1 and 2 were master pieces precisely because they let you write your own story more or less.
You could finish Fallout 1 without killing anybody, or massacre any young kids with a sadistic touch. You could go directly to the end game zone using stealth, or fast run to a ghoul infested city to save them for annihilation with the right timing. And when you succeeded in what you believed was your final mission, you were betrayed by your own family and discovered that's where the game really started! Hell, you could win the game by enrolling in the end boss team or convince him to suicide!
Bethesda's fallout is nothing like that, it's a vanilla yogurt. Fallout 3 is a disgrace of hidden linearity where children are immortal and the world is mostly static. Characters are Manichean and simplistic. The conclusion of the scenario falls so flat it's not even on the C major scale.
Writing a good Fallout is not following the game story, which is very vague, but rather embracing the twisted spirit, ludicrous humour and weird lore of the universe. If they go full "the boyz" + "z nation", amazon could pull it off. Not so much if they go "ring of power" + "the walking dead".
You cannot write a good fallout story with good vs bad characters.
New Vegas was good though. And Fallout4 was lazy writing, but good ideas overall. And the best Bethseda DLC ever was Far Harbor, it isn't even close. To me it's the best DLC, or at least the content DLC that added the most interesting story to any game.
The reality is that fo 3/4 reached more people than 1/2 ever did. Hence the popularity.
In any case... People need to write stories vs just rehashing all the ones we already got. I mean how many resident evil movies and shows are there? Far more than there should have been.
After all, mass effect was a tremendous success because and most people playing it thought it was a fantastic RPG experience despite tunnel like gameplay, stolen storyline, blend characters and horrible UI. Halo was more emotionally engaging and it was bloody FPS! But they didn't know how incredibly deeper RPG were 10 years before it when it was a niche genre.
Anything that is reaching mass adoption is at the risk of being a shadow of itself.
Baldur's gate 3 is the delightful exception, not the rule.
Fallout 2 let you become a drug dealer, a porn star, enroll in a cult or trigger the end of the world, and they could only display 960x540 pixels.
Fallout 3 lets you look at a mushroom cloud in HD from a distance with zero emotional impact, and call that being a bad boy because of all the anonymous zeros and ones you killed.
Doesn't matter. Whether you use Python, JS, PHP or Ruby, you will need to reach millions of users before perfs become a problem for a typical web app because the hot path are almost never coded in the language.
It's not a ruby thing, it's just that servers are beast nowadays, and cheap.
Servers cost, but server cost in absolute terms hit few people before you're big enough that the cost of capital to address it is far lower. And almost any money you invest in trying to minimise server costs at an early stage will end up going out the window because the features you end up needing at scale and that end up costing money to scale will tend to look entirely different from what you started with.
So even if you need to switch languages down the line, I'd argue you should pick your initial tools based on what lets you iterate fastest early on, not based on what will keep your server costs down the line. Assuming of course what you pick is fast enough for whatever you want to do.
Put in more concrete terms, based on the actual VC deals I've been on one or the other side of the table for, the cost of capital drops to anything from 1/2 to 1/10 per early round if you're doing well. If you do well enough that your server cost is becoming a problem, by the time you need to address it paying to address it ought to not be a problem unless your decisions were truly pathological.
Most companies don't survive long enough for this to become a problem.
In other words, while performance matters, the value of performance now to an early stage startup is often really low compared to speed of delivery that might improve your odds of actually surviving to a point where performance becomes a problem, and you might easily be willing to trade 2x, 5x, even 10x the total dev cost in cash to deliver faster if you can defer a significant portion of that cost a few years down the line assuming you survive that long and your cost of capital in terms of proportion of equity is a tiny proportion of what it is at the start.
This is not an argument for Rails, btw. This is an argument for whichever tool is fastest for YOU and YOUR team to deliver with. If you have multiple alternatives you're equally productive with and one of them is more performant than others, of course pick that one.
This debate has been going in circle over and over. It's the same arguments than 10 years ago, and the answers are the same.
No it's not saying bad performance doesn't matter.
Yes Go can make application more responsible.
But you have to balance out a lot of compromises in a project, and Pareto tend to favor those languages in the majority of situations because of cost, skills, resources and constraints.
Yes, I've used shiv and PEX in the past, and I love those. But that means "adding a build step". Also, as far as I understand, by default, those tools normally decompress the generated zip file on startup, but the decompressed artefacts have to be manually cleaned.
I think they are worth for more complex apps (I actually have a draft blog post with some experiments I did using PEX + gunicorn), but for my use case, it's not worth the effort when I only need the standard library.
#! /usr/bin/env -S pip-run Jinja2==3.*
from jinja2 import Environment
env = Environment(autoescape=True)
template = env.from_string("Hello, {{ name }}!")
print(template.render(name="world"))
There is a downside. Because pip-run recreates the virtualenv every time, the script takes a second to start up. pipx will cache virtualenvs once the single-file script feature is released. I haven't used fades yet.
Edit: fades caches virtualenvs.
#! /usr/bin/env fades
from jinja2 import Environment # fades Jinja2==3.*
env = Environment(autoescape=True)
template = env.from_string("Hello, {{ name }}!")
print(template.render(name="world"))
True -- but the ultrawealthy are largely concentrated in the USA. There are substantial impacts from renouncing for tax purposes, as well -- for instance, the Reed Amendment means that people who renounce their citizenship to avoid paying taxes are barred from entering the USA in perpetuity.
Additionally, there is an exit tax which captures unrealized gains upon renunciation.
So, yes, American citizens are a small percentage, but if the USA adopted wealth taxes, it would have an outsized global impact.
Yes, but my point was global. Everybody knows where the wealth is located but taxes and confiscation affects every country around the world event the poorer ones.
Stability, long time horizons, can adapt the law to their need, a communication on patriotism, no incentive to squeeze money out of every step, employees protection...
Every weakness can be a strenght depending of the context. Good profiles that would not consider working in high pressure, high risk envs like spacex can be interested in gov projects.
Because anecdotally, the cops that interacted with me and people around me where completely uninterested in doing any kind of work, no matter how easy it was.