simplotek

From the article:

> The point I am trying to make? If you dislike Twitter’s new direction, why don’t you quietly close your account and find a new home?

This is a small glimpse of the shamelessly apologetic white knighting that emanates from the article. A billionaire cannot do no harm or be held to scrutiny because, as the result of a major screwups, was forced by a court of law to purchase a company. Said billionaire cannot be scrutinized when he's speed running through the destruction of a service used by the whole world. Said billionaire cannot do any harm because another billionaire stated he bought other companies.

Does the validity of any criticism directed at Elon Musk change depending on the net worth of anyone criticized for making the exact same torrent of errors?

> Same with the whole "serverless" thing heavily pushed by Amazon and co which conveniently offer "serveless services". These trends are always pushed by marketing departments at SAAS companies.

This take is pure nonsense. It's highly disappointing to see this blend of ignorant and uninformed take in HN of all places.

Amazon's serverless offerings are the ideal tool for many use cases, specially internal services. Instead of being forced to write, deploy, operate and maintain a dedicated service to handle events, just write the event handlers you need, get it to run in someone else's computer, and forget about it.

Internally, things like AWS Lambda saves a lot on wasted allocated capacity. You don't need to waste allocating a whole box to run a handler each time, say, someone uploads a file to S3.

> For example "uncle bob" delivers a lot of his advice as gospel, but has he actually successfully delivered any software that's used at scale?

I fail to the the point in this cheap ad-hominem.

Uncle Bob is arguably best known by his seminal books: Clean Code, and Clean Architecture.

Clean Code talks about principles such as "you should name your variables well". Why do you believe scale is any relevant?

Clean Architecture talks about a general principle to organize software projects which has traits that are highly benefitial to maintenance, refactoring, and even re extensability. It's a nuanced take on the tried and true layered architecture. Why do you believe scale is remotely relevant?

I know personally Principal Engineers of a couple of FANGS who are great at selling ideas but are outright awful at writing code. One even famously handed POCs to SDE1s to have them rewrite and refactor his code to get some quality in it. Do you really believe in this appeal to authority fallacy to the point where the number of customers hitting a server are the measuring stick for competence and the quality of implementations?

> Throwing things on a blockchain is a mile backwards for most use cases.

But the buzzwords. Think about the buzzwords.

> As a regular code reviewer, I’ve grown to dislike extension methods quite a bit as it violates the principle of least surprise.

I disagree. The common use case for extension methods in ASP.Net Core apps is to extend the builder to apply configurations like all other projects. This pattern is so pervasive that the surprising outcome would be if a member function was not an extension method.

> It vastly reduces the complexity of things like dependencies, testing, CI/CD, versioning.

Did it, though?

The only conceivable advantage is version pinning. I makes absolutely no difference in terms of test coverage whether you use a monorepo or not. Dependencies-wise, the only thing that a monorepo saves is releasing individual components, which ultimately is not an advantage but a drawback and a liability.

So exactly what's the upside, if any?

> If you put microservices in a monorepo (...)

What exactly do you gain with this approach, other than pinning versions of all microservices?

Any competent team working on services does not suffer from "versioning hell" because APIs are stable and tracked with integration tests and smoke tests, and you version the API and not the code.

> This always seemed strange to me. If your team can't be trusted not to make spaghetti in a monolith, what stops them from making distributed spaghetti in microservices?

It's far harder to update multiple services to handle requests they should not handle, let alone update a deployment to allow those requests to happen.

Walls make great neighbors, just like multiple services make teams great at complying with an architecture constraint.

This phenomenon is not limited to the US. Real estate prices in some European countries skyrocketed in the past couple of years to the point where middle class families with two sources of income are unable to afford a two-bedroom apartment in a medium-sized city, and can barely afford renting it too.

Good luck getting a bank loan for around half a million dollars to buy a three bedroom apartment in a country where the average income before taxes is well below €50k/year.

Something happened to the world economy after mid-2010s where demand for real estate grew like crazy as a kind of store of value/hoarding investment. The scapegoat keeps on shifting, from Airbnb to work-from-home to whatever lame excuse, but it's the same phenomenon everywhere.

> This issue is asking Odin to move away from Visual Studio (by which I assume they just mean the MSVC toolset), which is by far a highly preferred environment for C++ programming on "[0].

Your source does not support your claim at all.

Even though vscose and Visual Studio are reported as popular IDEs, you're not talking about IDEs. You're discussing compilers and compiler toolchains, which is not the same thing as a IDE. Microsoft's msvc compiler is not the same as Microsoft's Visual Studio. Visual Studio is an IDE which, among other things, uses msbuild and msvc compiler.

The poll you quoted states that 78% use GCC regularly, followed by clang being used regularly by 43%. Microsoft's msvc compiler is in 3rd place at 30%. The same poll also points out that 55% uses cake and 36% use Makefiles regularly, and Visual Studio projects showing up in 3rd place with 31%.

> The ad-hominem isn't advancing your cause lol.

There was no ad-hominem. OP pointed out your initial claim contrasts with the facts.

> Rust defaults to the MSVC toolchain. Surely you knew that. (...)

This reads like a non-sequitur. The claim you've replied to was that Odin had poor windows support, and OP pointed out that Rust also supported Windows without msvc toolchains.

> You're the only one here complaining about MSVC.

Sorry, you're clearly speaking while oblivious to the discussion. The message you've replied to includes a link to a ticket asking Odin to shed it's dependency on msvc. It's clearly titled "move away from msvc".

https://github.com/odin-lang/Odin/discussions/2047

I believe you owe OP an apology.

> The UX is admittedly awful, but once you get familiar with its warts submodules are entirely usable.

The point is not how much effort you need to invest in getting git submodules to eventually or occasionally work.

The point is whether vending the subproject as a prebuild library/package is simpler or not, or whether it requires more work or not.

And it's abundantly clear that submodules are always inferior to vending packages, not to mention they are audit-friendly.

> Autoconf is just a complicated system for finding and detecting third party libraries. If an application just uses the standard library, the build system can be very simple and reliable.

It's slightly more than that.

Autoconf is a Makefile generator. It was designed to do system introspection and perform sanity checks, and configure projects so that they could be built and installed in multiple platforms.

It's always possible to switch back to Makefiles. You'd be foregoing sanity checks, abstractions that come for free, and you'd have to fill in the blanks left out by missing features such as what compiler I use and how to configure the compiler and how to put together Release and Debug builds and how to consume dependencies and where do I install the project.

Complaining about build systems is like complaining about a high level language: you might focus on the bloat, but you completely miss the extra work you have to reinvent the wheel and have to maintain it forever.

I worked on projects where rebase was the norm, even for public feature branches.

Not a problem.

Rebase is a tradeoff of handling merge conflicts with achieving a commit history that is far cleaner and audit-friendly.

The point being that some technical choices are not black and white, and people mistake baseless personal opinions with technical truths. There's an awful lot of workable grey areas with tradeoffs.

If a team member insists on pushing his personal opinions as the truth, challenges and opposes each and every proposal that does not match his personal opinion, and drags on personal vendettas in decisions that didn't went their way... I'd say that no matter where their tech skills are, that person is still incompetent and a liability in any team.

> Some friction in decision making will often yield better decisions.

I agree. The problem starts when this sort of friction continues after all the decision-making is done and starts manifesting as contrarian positions towards how the project is being conducted, always insisting that their idea was better, and even assuming aspects of sabotage.

It's one thing to determine a path forward, but an entirely different thing to assume a "my way or no way" stance.

>>And this is why skilled people can't find a job. Unless you can kiss a*s you won't get hired.

You're trying too hard to rationalize away personal problems and your inability and/or unwillingness to address them.

The opposite of disagreeable is not "kissing ass". The opposite of disagreeable, to start off, is not being a total asshole. No one's technical prowess is impressive enough to ignore the fact that they are completely insufferable. A project survives extra weeks or even months, but a team does not survive an eggeegious team member who makes everyone around them miserable.

Take a long hard look at yourself before throwing blanket accusations at anyone and everyone around you.

As the saying goes, "if someone is an asshole, they're an asshole, if everyone is an asshole, you're the asshole"

> (...) but I believe that Syntax 2 is an excuse create a new language and reuse the C++ name.

This. It looks like a blatant attempt to ride the coattails of C++, which oddly enough is not the first case coming from Redmond (see C++/CX).

If the concept is able to fly on its own without these marketing crutches then it would be more credible to just claim it's a successor.

> (...) so the three of you combined did have income of 8€.

The whole point is that that is not income, but just an aggregate value of all transactions within an economy. Money exchanged hands, which is not the same as someone's income.

> Kotlin - statically + strongly typed, try making an android app!

Wrestling the frameworks of the moment tend to dominate the cognitive load of developing mobile apps in general, including Android. More often than not, whatever programming language that's used ends up feeling like glue code for life cycles and frameworks, which is suboptimal in terms of the goal of picking up a new language.

My 0.02€

> You don't agree with the tiny sliver of the NSA mission that you know about.

Strong "trust me bro" vibes.

Hand-waving and baseless assertions don't contradict the fact that it conducts activities against it's country's most basic founding principles and laws.

This regrettable line of argument is in line with blindly defending the police in spite of all the police murders, abuse, and outright corruption.

> As such, it also measures the income earned from that production, or the total amount spent on final goods and services (less imports).

It's my understanding that the "income" interpretation refers to tax income, because each transaction is taxed.

Take a look at your quote. It says it's also the "total amount spent on final goods and services". If you buy bread for 1€ and ham for 1€ and sell ham sandwiches for 6€, no one had income of 8€. At most, the state charged VAT on your 2€ purchases and 6€ sales.

> Attributes are better suited for that. #pragma has always just been a grandfathered in hack.

I'm not so sure attributes are better. They have political traction, but that does not mean better. All major compilers use pragmas effectively to implement custom compiler flags. See for instance how Visual C++ uses pragmas extensively to toggle specific compiler warnings, not to mention the infamous #pragma once

> GitHub is also owned by Microsoft.

GitHub was bought by Microsoft in 2018.

Recently Microsoft announced they were killing off GitHub Atom.

Being able to use the latest release of a dead project is no big reassurance.

This might be an anecdotal case, but it is indeed real world proof that a project being backed by a company the likes of Microsoft does increase the odds of being killed off.

> personally i would skip straight to kubernetes if you start messing with swarm

I don't know. Docker swarm mode is basically Docker spread over multiple nodes. Consequently it's a very spartan Kubernetes-light, but extremely easy to operate and maintain.

I love microk8s but I still find Docker swarm mode to be the ideal first step for on prem.

> Pragmas are processed by the pre-processor, so they aren't appropriate for expressing control flow hints.

I don't thing this is remotely true. C++ pragmas were designed with the express purpose of providing additional information to compilers.

> Some necessary features weren't even supported in the current Docker-Compose file versions.

Why docker-compose?

Have you tried Docker swarm mode?

> Broadly, maybe. At work, I don't care about being liked by people that can't admit they are wrong.

Why do you presume all outcomes of your eggregious interactions is placing blame on others?

It seems you are totally oblivious to some of the most basic principles of working in a professional environment: if you antagonize and attack your team members, you are not trusted to help out and have their backs. This means you are not an asset but a liability. Working close to you is making them vulnerable to being stabbed in the back by you at the slightest issue. And that's why you are not liked, even if/when you are right.

All the people can be right, but that doesn't justify you insisting on pissing on everyone else's cereals.

> (...) but let's not trivialize how insanely easy Docked made creating containers become.

So much this. Docker doesn't get the respect it deserves. I'd also mention packaging/installing/deploying applications, which Docker made so trivial and trouble-free.

Docker at it's core is a masterclass of UX.

> Does this relate to the normal modes or eigenmodes of a system?

Yes. The eigenvalues and eigenvectors of an undamped harmonic oscillator are respectively the vibration frequency and vibration mode.

One major class of structural analysis techniques is modal analysis, which determines the vibration modes and corresponding frequencies of specific structural systems subjected to particular boundary conditions.

> Sure, if you're developing a SaaS you can stay on top of .NET versions but it's definitely causing friction for enterprise and slow moving regulated software.

You have a point, but I'd call out that migrating to newer releases can and often is trouble-free.

A couple of months ago I worked on a .NET Core 2 web service that was put on cold storage for a few years, and all it took to migrate it to .NET Core 6 was a few version number bumps and a rebuilding the project.

YMMV of course, but LTS shelf life might not be a deal breaker.