I still don't think a large portion of .NET developers know that adding optional parameters is a (binary) breaking change.
Requests on details here - fair enough!
Let's say you have a method in a library:
Get(string foo)
Caller: Get("test")
You add an optional param, let's say:
Get(string foo, int bar = 0)
("Type is not important here")
Without a re-compile, that's a missing method exception.
Why? Because the method was Get(string), now the method is Get(string, int).
Optional params, importantly, are baked in *AT THE CALLER*. So if your code is calling:
Get("test")
...what that's actually compiling to is:
Get("test", 0)
(whatever the default was at compile time)
This also means changing the default value from say 0 to 2 in this example, is a breaking change. People compiling against you when it was 0 have 0. People who compiled at 2 have 2. Upgrading the library reference will not change the constant they compiled *at the call site*.
In short: adding an optional param to a method breaks binary compatibility because the signature that callers are looking is no longer there...they're looking for the old one, with one less parameter.
I hate to see a new contributor bitten by this, but yeah: that's how it works.
Also note: breaks via transitive refs are an extra layer of fun here you may not even realize. This simple friendly example assumes people respecting SemVer...if they don't, it's even worse :)
It's very important to realize that some people are working remote by choice. And many more (right now) are doing so by necessity. The latter is basically an invasion of work into their home.
These are not people working at home because they want to, they're camping and coping.
In our house, I work remote by choice (for over a decade). My wife is working remote because her company closed their offices (now permanently). Add in kids needing space for school every weekday and...oof.
Nothing about this is normal. And I'm an introvert who recharges solo.
There are no redeeming qualities. None. There’s a hardware shortage everywhere, they gobble energy supply in a completely unsustainable model, and almost everyone involved is only doing this to make money…in another currency.
The entire thing is based around consuming energy and occupying hardware. The value is 100% imaginary. The system is based on a perceived value, and given people are in and out to make money off that perception: it’s basically a pyramid scheme.
Cryptocurrencies are a blight.
Oh look, all the bitcoin fanatics are coming to change my mind!
The last 3 days is one of the longest deep dive debugs we've had in years. We finally got the culprit for some timeouts this afternoon: the compiler. It eats more CPU in a later version, not by much, but enough. Here's a segment of our build with .NET SDK 3.1.402 vs. .NET 5.0.101
Note: we've run builds on our web tier for the past decade. Why? Because they're typically at 5-10% CPU and we don't have a lot of hardware - so we used the spare capacity. Now, with Roslyn pegging all cores in that spike, it finally hurt.
Let's walk through the past few days.
Typically, our web tier is very idle, you could say it's boring. Thread pool queues sit at 0, the largest app sits at 1-4% CPU, and concurrent requests are generally sub-10 (because they're in and out fast). It looks like this (last 7 days - note the spikes the past few days):
We're currently working on a way to dump all threads from the current app pool somewhere when an event occurs to narrow down the blocking issue. This is getting fun, processes dumping themselves.
We are definitely calling this method Dumpster.Fire();
I explained this a few times today, and I think it's important for every dev to know: timeouts are not necessarily what they seem.
A timeout happens when an operation doesn't complete fast enough. But, what does that mean? What are the details of that check? Well...
You almost never check timeouts live, unless doing so is VERY critical and worth being a primary CPU consumer. That's very expensive. Usually, what happens is one of 2 things:
- A timeout event is queued, and if it goes off first: boom.
or:
- Timeouts are checked on an interval.
If you check timeouts "live", well...nothing's "live". It's some period of time, even if it's 1ms.
To queue a timeout with the event and you're checking both: that means another item to track and schedule, which means cost, that scales.