chipdart

You can learn from everyone around you, regardless of their status. There is no "universal developer experience curve", everyone has more or less knowledge on a field or with a specific tool/framework.

There's a big difference between learning from someone and having someone teach you something. The latter expedites your progress and clarifies learning path, whereas the former can even waste your time with political fights pulling you into dead-ends.

But a warning: you will spend years in the weeds, focusing on things that don't matter.

That sums up anyone's college experience.

The hard part is telling apart what doesn't matter from what does. More often than not, what dictates which is which is the project you find yourself working on.

C# has this:

This is only syntactic sugar to allow using object initializers to initialize specific member varabiles of a class instance instead of simply using a constructor and/or setting member variables in follow-up statements. It's hardly the feature OP was describing.

The problem is that programming languages have always focused on the definition side of types, which is absolutely necessary and good, but the problem is that only limiting use by, e.g., "protected, private, friend, internal, ..." on class members, as well as the complicated ways we can limit inheritance, are barely useful.

Virtually all software ever developed managed just fine to with that alone.

I don't know of any programming environment that facilitates properly specifying calculating something even that basic in the init phase of running the system, (...)

I don't know what I'm missing, but it sounds like you're describing the constructor of a static object whose class only provides const/getter methods.

or even a db table's row(s).

I don't think you're describing programming language constructs. This sounds like a framework feature that can be implemented with basic inversion of control.

For every project/job/app that needs the AWS levels of resilience (...)

I don't think you're framing the issue from an educated standpoint. You're confusing high-availability with not designing a brittle service by paying attention to very basic things that are trivial to do. For example, supporting very basic blue-green deployments that come for free in virtually any conceivable way to deploy services. You only need a reverse proxy and just enough competence to design and develop services that can run in parallel. This is hardly an issue, and in this day and age not being able to pull this off is a hallmark of incompetence.

They run a Wireguard network between the nodes so you can have a mix of on-premise and cloud within one cluster.

Interesting.

A quick search shows that some people already toyed with the idea of rolling out something similar.

https://github.com/ivanmorenoj/k8s-wireguard

We will charge € 1/TB for overusage.

It sounds like a good tradeoff. The monthly cost of a small vCPU is equivalent to a few TB of bandwidth.

yes, like i said, (...)

I'm sorry, you said absolutely nothing. You just sounded like you were confused and for a moment thought you were posting on 4chan.

I loved the article. Insightful, and packed with real world applications. What a gem.

I have a side-question pertaining to cost-cutting with Kubernetes. I've been musing over the idea of setting up Kubernetes clusters similar to these ones but mixing on-premises nodes with nodes from the cloud provider. The setup would be something like:

- vCPUs for bursty workloads,

- bare metal nodes for the performance-oriented workloads required as base-loads,

- on-premises nodes for spiky performance-oriented workloads, and dirt-cheap on-demand scaling.

What I believe will be the primary unknown is egress costs.

Has anyone ever toyed around with the idea?

Demoralized or denormalized?

The database is denormalized. The developers are demoralized.

Are you one of the reasons why SEO spam sites are clicked on so often?

I don't think your poorly thought-through personal attack has any relevance to the topic. I clicked on the article because there was a submission in HN with the title "Myths and Urban Legends About Dual-Socket Servers". What leads you to believe SEO holds any relevance

I'm an independent developer right now, building systems for businesses and there is literally no better way to deliver line-of-business internal applications than via a monolith.

This is the same sort of myopic, naive, clueless take that led people armed with this blend of specious reasoning to dive head-first onto microservices architectures without looking at what they were doing and thinking about the problems they are solving.

The main problems that microservices solve are a) organizational, b) resilience, c) scalability.

If you work on single-person "teams" maintaining something that is barely used and does not even have SLAs and can be shut down for hours then there's nothing preventing you from keeping all your eggs into a single basket.

If you work on a professional environment where distinct features are owned by separate teams then you are way better off running separate services, and perhaps peel out shared responsibilities to a separate support service. This is a fact.

But let's take it a step further. You want to provide a service but some of the features are already provided by a separate service either provided by a third-party or whose project you can simply download and run as part of your deployment. Does this count as a microservices architecture to you or is it a monolith?

Consider also that your client teams have a very specific set of requirements and they rolled out services to provide them. Is this a microservices architecture or a monolith?

Consider also that you start with a monolith and soon notice some endpoints trigger workflows that are so computationally demanding they cause brownouts, and to mitigate that these are peeled out of the monolith to dedicated services to help manage load. Is this a monolith or microservices?

Consider that you run a monolith and suddenly you have new set of requirements that forces you to do a major rewrite. You start off with a clone of the original monolith and gradually change functionality, and to avoid regressions you deploy both instances and have all traffic going through an API gateway to handle dialups. Is this microservices or monolith?

The main problem with these vacuous complains about monoliths is that they start from a place of clueless buzzwords, not understanding what they are talking about and what problems are being addressed and solved. This blend of specious reasoning invariably leads jumps from absolutisms to other absolutisms. And they are always wrong.

I mean, if problems are framed in terms of fashion tips, how can the possibly be right?

What an appallingly bad article. It starts with a premise only backed with an unsubstantiated and outright false appeal to authority ("the likes of Amazon are moving to monoliths!1") and proceeds to list a few traits that are so wrong they fall into the "not even wrong" territory. For example, things like "incorrect boundary domains" and circular dependencies are hardly related to how distributed services are designed.

This nonsese reads like a badly prompted machine-generated text.

The whole point of CI is to automatically verify the code.

Against errors and regressions. Meaning, stuff that breaks your code and affects the service you provide to users.

Style issues ain't that. Come on.

(..) you really want those 2x 12 memory channels a Dual EPYC system offers (...)

I had to check and I was amazed that there are companies selling workstations with dual EPYC processors, providing a whopping 256 CPU cores and over 2TB of DDR5. All in a desktop form factor. Amazing.

Intel will have more cores shortly.

The article was posted in 2023.

It does but it also seems like AMD is saying just buy one CPU, which is weird because you’d think they would want you to buy two to double the profit.

The are saying "buy a single EPYC instead of two of our competition".

This article reads like an AMD advertisement for their EPYC processor line.

Aren't the drivers being hired for their recently announced Robo-Taxi fleet (...)

The robo-taxi fleet is scheduled to be launched by 2026. This means Tesla, in spite of Elon Musk's wild claims, is not counting on providing anything remotely similar to FSD until at least 2026.

Well, the share is up 3% since that article was published. :shrug: , I guess ?

I don't know where you get your stock quotes. The ones I get tell that last monday TSLA stock prices were at around $350 and right now they stand at $345.

Requiring manual intervention to handle a blocked pipeline over a non-issue defeats the whole purpose of continuous integration, not to mention that you are suggesting adding twice the complexity as an alternative to not adding any complexity at all.

And should I stress again that there is absolutely zero positive tradeoffs?

This is genius.

This is a peak Elon Musk stan quote: playing catch-up to what is described in the article as the industry standard, and something that established players were doing over a decade ago, is... "Genius"? Is that it?

What does the word "genius" mean to you at this point?

Also, it seems like it's already done in other robotaxi setups.

I think you're missing the whole point.

The whole point is that Tesla has been promising full self-driving cars for years, and going as far as to talk shit about specific computer vision strategies used by competitors with actual real-world autonomous car services being provided to the public. Elon Musk has been promising the public that full self driving was just a software update away for those who spent money on a Tesla car with a specific onboard computer.

And now, after years of making promises about full self driving cars and shitting on companies who already provide autonomous car services, they silently decide that after all they "need the ability to access and control [Tesla cars] remotely” ?

I mean, using teleoperators is a widely known industry standard. Tesla was promising way more than that and shitting on those who were using them. And now apparently they are scrambling to catch up with what Waymo was doing over a decade ago?

If I was a shareholder or a customer, I'd be pissed.

“duped” isn’t the right word here.

"Duped" is an accurate description of how Elon Musk has been treating customers who bought a Tesla car with a HW3. He's been repeatedly promising those buyers that full self driving is just a software update away. Now apparently FSD is an impossibility and the company is rushing to hire drivers? In the very least it's bait-and-switch scam.

Big pile of nothing.

Not really. In the very least it proves that at best Tesla is way behind established robotaxi operations, and once again demonstrates that Elon Musk's recurrent promise that "full self driving cars is just around the corner" is just a blatant lie to fool investors. I mean, think about it: if Tesla's promise of full self driving was indeed around the corner, why would they suddenly feel the need to hire teams of drivers to drive there cars?

Linting and style guides are not of "critical importance".

This is simply false, as attested by the huge volume of comments in this thread by those with actual professional experience working on real-world software projects.

You're also oblivious to the problem domain, because otherwise you'd understand that the critical problems are not whether a space should be at the left or at the right of a symbol, but all the churn that is required to manually address style problems in PRs.

Try to think about the problem. You post a PR that screws up all formatting. It takes time for a team member to review a PR. Once you start to get reviews,you notice comments pointing out failures in complying with a specific style. Whether you go the passive-aggressive path of waiting for any other team member to review your code or you do the right thing and fix the problems you introduced, that requires another round of PR reviews. The time that you take with each iteration is the time your work is delayed to be merged. Now think about how many hours per month you waste just because you can't manage to format your code properly.

style fixes should always be separate commits.

Not really. If you're already changing the code and running linters afterwards introduces changes over your change, this means you are the one introducing the problems. Separate commits just add noise.

Your comment is like saying that bug fixes should be separate commits when arguing about how not to add bugs to begin with.

You can revert and even force-update the branch to rewrite it's history, but GitHub still tracks the old commits and even lists in the PR the events that rewrote the branch history.

If you start telling people off at work, there is a good chance that you will be perceived as being the problem

The whole concept of a PR is to review the changes you ask your team to pull into the repository.

What do you think PR comments are intended to be? Pats on the back and public announcements on how awesome you are?

No, the whole point of a PR is to allow others to review the changes you proposed so that the mistakes you are trying to introduce are easier to spot and prevent.

What do you call comments that flag a problem with your code changes? Do you call it "being the problem"?

If there's a team agreement and someone continues to violate it (...)

How will they tell if you do not point out those violations in the PRs? That's precisely why they exist.

CI should reject the feature branch if the linter fails.

Your CI pipeline is broken if it refuses to run because of style issues. Linting is either applied as a pre commit hook or manually by the developer. Anything else is a mistake you are making without any concrete tradeoff.

The same goes for other mistakes such as handling warnings as errors.

Imagine going into a meeting with a senior manager and explain that you cannot release a hot fix because your pipeline is broken due to the last commit having 5 spaces instead of 4.