Every job lately seems to have been infected by Meta/google “data driven” leadership. Its so painful and wasteful sometimes.

It's cargo cult mentality. They look at FANGs and see them as success stories, and thus they try to be successful by mimicking visible aspects of FANG's way of doing things, regardless of having the same context or even making sense.

I once interviewed for a big name non-FANG web-scale service provider whose recruiter bragged about their 7-round interview process. When I asked why on earth they need 7 rounds of interviews, the recruiter said they optimized the process down from the 12 rounds of interviews they did in the past, and they do it because that's what FANGs do. Except FANGs do typically 4, with the last being an on-site.

But they did 7, because FANGs. Disregard "why".

C++ continues to be the dumping ground of paradigms and language features. This proposal just aims to add even more to an overloaded language.

I think you could not be more wrong even if you tried, and you clearly did not even read the proposal you're commenting on.

This proposal aims to basically create an entirely different programming language aimed at being easy to integrate in extsting codebases. The language just so happens to share some syntax with C++, but you definitely can't compile it with a C++ compiler because it introduces a series of backwards incompatible changes.

It's also absurd how you complain about introducing new features. Can you point out any language that is not absolutely dead that is not introducing new features with each release?

C++ programmers mocked languages for being dynamically typed then they introduced auto (...)

I'm sorry, you are clearly confused. The auto keyword is not "dynamically typed". It is called "auto" because it does automatic type deduction. It is syntactic sugar to avoid having to explicitly specify the type name in places the compiler knows it already. Do you understand what this means?

Your comment sounds like trolling, frankly.

They’re a member, because they find Rust useful. This is just them saying another time that they find Rust useful.

Fans of a programming language stating they like the programming language is hardly thought-provoking stuff. There are also apps written in brainfuck and that means nothing as well.

Is there something else I’m not seeing?

Possibly payment processing fees. Some banks/payment institutions charge you for a payment.

Git is ugly and functional.

I don't even think it's ugly. It just works and is intuitive if you bother to understand what you're doing.

I think some vocal critics are just expressing frustration they don't "get" a tool they never bothered to learn, particularly when it implements concepts they are completely unfamiliar with. At the first "why" they come across, they start to blame the tool.

Incidentally, this kind of passive-aggressive pressure is the kind of thing that might be considered a legitimate security threat, post xz.

Yes, OP's attempt to bully a maintainer into accepting his PR is a very shitty thing to do.

Throwing veiled personal attacks, such as insinuating a developer is incompetent or dumb, is also very bad form.

This says more about OP than anything. I hope I never have to work with anyone like that. What a shit show of a person.

OP,

Here's a friendly reminder that programming.dev has a community dedicated to .NET: !dotnet@programming.dev

If you need anything more complex than cherrypick, you already screwed up big time.

I think this is a clueless comment. You can use Git to greatly improve your development workflow if you dare going beyond the naive pull/commit/push workflow.

Take for example interactive rebase. It let's you do very powerful stuff such as changing the order of commits in a local branch and merge/squash contiguous commits. This unlocks workflows such as peeling off bugfix and cleanup commits from your local feature branch without having to switch branches. I'm talking about doing something like:

a) - you're working on your task, b) - you notice a bug that needs fixing, c) - you fix the bug and commit your fix, e) - you continue to work on your task, f) - you notice a typo in your bugfix code, so you post a fixup commit. g) - you post a few commits to finish your task, h) - you noticed your bugfix commit didn't had the right formatting, so you post a couple of commits to lint your code both in your bugfix commits and task.

When you feel you're done, you use interactive rebase to put everything together.

a) you reorder your commits to move your bugfix commit to the top of your local branch, followed by the typo fixup commit and the linter commit. b) you mark both the typo and linter commits as fixup commits to merge them with the bugfix one, c) you post a PR with the single bugfix commit, d) you finally post a PR for your task.

Notice that thanks go git interactive rebase you did not had to break out of your workflow or do any sort of context switch to push multiple PRs. You just worked on things you had to work, and in the end you just reorganize the commit history in your local branch to push your work.

Is this what you call "screwed up big time"?

We spend so much time building devices that are meant to break, and be unfixable, and making software that fights the user instead of helping.

Kudos to the EU for forcing mobile phone manufacturers to support replaceable batteries and standardize on USB-C charging.

Is it just me or is this a nightmare implementation in terms of software maintenance and operations? Each state transition requires a database trip, state machine transitions are determined at runtime and there's no simple way to reproduce them locally, and in the case of the state machine database going down the system simply cannot work.

What exactly is the selling point of this approach?

You can’t both be a good meeting-place for experts and a good place for novices to get expert advice and an advertising venue.

I don't agree. There is no clear cutout between what means to be an expert and a novice. What content you're exposed to is the output of the service's support for user profiling and search. It is simply not possible to get rid of an important subset of your customer base without causing false positives and generate ill-will. Finally, we should keep in mind that yesterday's novice is today's expert.

Here’s another: most code reviews on larger companies are BS, just for show and nitpicking.

Story time.

Once I worked with a developer that just joined the company straight out of college, and had far more ambition than competency. That developer decided that code reviews where the venue where their high bar for code quality would shine, so they decided to nitpick everything that went against their poorly formed sense of taste. As luck would have it, the developer was assigned to a legacy project that was in cold storage for years and had no tests and linters, and was in a really poor state, and proceeded to leverage that to challenge each and every insignificant detail such as if a space should be at the left or at the right of a symbol. Each code review automatically received dozens of comments nitpicking whitespace changes. What a waste of time with so much noise.

I drop by the project, and noticed the churn that developer alone forced upon everyone, as that team had a rule that all code reviews should be passed by all reviewers and that reviewer made it their point to reject reviews that didn't complied to their opinion on whitespace. So the first thing I did was onboard a code formatter, and made it my point to subject the spec to an unanimous code review. That problematic developer made it their point to nitpick away each and every single setting, but it turned out some of their opinions conflicted with previous feedback.

So the code formatter tool was onboarded onto the team. Did that stopped the problematic developer from continuing their nitpicking? No. Except this time around other developers started pushing back because the opinions were contradictory and contrasted with the official code formatting style.

All it took was a couple of days for the problematic developer to go from dozens of comments per day to zero. The code formatter was still optional and not fully adopted, but the problematic developer simply ceased with the bickering.