Am I saying you are scientifically illiterate?

Based on the previous statements, yes. However, as a matter of fact, not necessarily insult.

The good news is you’re following up with questions and want to learn more, instead of doubling down. With curiosity you will become more literate.

Maybe you were born with all the knowledge of the human race, but the rest of us have to learn it.

The education system in the country you are from has failed you. Assuming you are in your mid-late teens, or older, scientific topics should have already been taught in what North America would call “middle school” (11-14 years old). That teaches you things like conservation of momentum.

There is a reason why it’s called illiteracy, because there is an expectation that the baseline level of education everyone in developed countries receives teaches them the fundamentals of how the world around them works. Without this fundamental understanding it’s not possible to understand more complex topics that build upon it, stunting growth.

They’re not on to anything here. As further stated by your comment.

Equal and opposite reaction.

There’s a law for this. The matter is “pushing” against the ship, it doesn’t have to push against anything else.

In fact having an atmosphere to push against actually reduces the effectiveness of thrust due to atmospheric pressure, which must be overcome. Which is why different engines are designed to run in atmosphere versus out of atmosphere.

If you throw a baseball in space you have transferred momentum to that baseball, pushing you back. You will move in the opposite direction (likely spin because you just imparted angular momentum onto yourself since you didn’t throw from center of mass)

Given how many people think that railguns have no recoil because “there is no explosion” they might actually seriously believe what they just wrote.

Scientific illiteracy is through the roof.

Or maybe it’s the same as it it’s always been it’s just that people that are scientifically illiterate are given platforms to speak their illiteracy as truth.

Because your conservative funded news outlets have a very overt goal here.

The CEO is a right wing trump worshiper.

Dig into the company’s tweet history, and find archived tweets that were deleted for PR/white-washing reasons.

Long history of this stuff.

I mean… Every serious operating system already has some form of keyring feature right?

Not necessarily. There are many paths to exfiltrated data that don’t require privileged access, and can be exploited through vulnerabilities in other applications.

Yeah, and electron already has a secureStorage API that handles the OS interop for you. Which signal isn’t using, and a PR already exists to enable…

Never not UTC Everywhere.

https://utceverywhere.com/

The ecosystem is really it, C# as a language isn’t the best, objectively Typescript is a much more developer friendly and globally type safe (at design time) language. It’s far more versatile than C# in that regard, to the point where there is almost no comparison.

But holy hell the .Net ecosystem is light-years ahead, it’s so incredibly consistent across major versions, is extremely high quality, has consistent and well considered design advancements, and is absolutely bloody fast. Tie that in with first party frameworks that cover most of all major needs, and it all works together so smoothly, at least for web dev.

The designers as seen by designers is so right.

Nothing they come up with can be wrong, it’s all innovative!!

The follow on. Lots and LOTS of unrelated changes can be a symptom of an immature codebase/product, simply a new endeavor.

If it’s a greenfield project, in order to move fast you don’t want to gold plate or over predictive future. This often means you run into misc design blockers constantly. Which often necessitate refactors & improvements along the way. Depending on the team this can be broken out into the refactor, then the feature, and reviewed back-to-back. This does have it’s downsides though, as the scope of the design may become obfuscated and may lead to ineffective code review.

Ofc mature codebases don’t often suffer from the same issues, and most of the foundational problems are solved. And patterns have been well established.

/ramble

There is no context here though?

If this is a breaking change to a major upgrade path, like a major base UI lib change, then it might not be possible to be broken down into pieces without tripping or quadrupling the work (which likely took a few folks all month to achieve already).

I remember in a previous job migrating from Vue 1 to Vue 2. And upgrading to an entirely new UI library. It required partial code freezes, and we figured it had to be done in 1 big push. It was only 3 of us doing it while the rest of the team kept up on maintenance & feature work.

The PR was something like 38k loc, of actual UI code, excluding package/lock files. It took the team an entire dedicated week and a half to review, piece by piece. We chewet through hundreds of comments during that time. It worked out really well, everyone was happy, the timelines where even met early.

The same thing happened when migrating an asp.net .Net Framework 4.x codebase to .Net Core 3.1. we figured that bundling in major refactors during the process to get the biggest bang for our buck was the best move. It was some light like 18k loc. Which also worked out similarly well in the end .

Things like this happen, not that infrequently depending on the org, and they work out just fine as long as you have a competent and well organized team who can maintain a course for more than a few weeks.

Just a few hundred?

That’s seems awfully short no? We’re talking a couple hours of good flow state, that may not even be a full feature at that point 🤔

We have folks who can push out 600-1k loc covering multiple features/PRs in a day if they’re having a great day and are working somewhere they are proficient.

Never mind important refactors that might touch a thousand or a few thousand lines that might be pushed out on a daily basis, and need relatively fast turnarounds.

Essentially half of the job of writing code is also reviewing code, it really should be thought of that way.

(No, loc is not a unit of performance measurement, but it can correlate)

If you do this enough you know how to design your solutions to be relatively flexible. At least for your backends.

Your frontend will always churn, that’s the nature of the job.