> Like if you build an Excel formula, the mandatory async/await approach just doesn't work. It's not an asynchronous operation and runs into a UI context where you deadlock if you wait.
Last time I did excel interop it was COM based and there wasn't any async part of it. I'm curious if you were using COM interop also? Also, async/await was explicitly designed to work in UI contexts like Winforms and WPF where there is only a single UI thread...?
> It took like 15 years before they added a json serializer to the standard library..
That isn't really true. DataContractJsonSerializer [0] landed in .NET 3.5 which was in 2007. Admittedly, it kinda sucked but it was there and was usable. And also JSON.Net was around by that point and was/is excellent.
> ...and don't even think about support for any new major image format (webp, heic).
Image support on windows was historically provided by WIC [1] and does support the formats you talked about. But you are correct that native .NET support for many image formats is non-existent.
> And because they broke backward compatibility on so many libraries, it's a non trivial effort to convert a complex code base to core.
This is very true, and I felt it firsthand. My employer still has a codebase on .NET Framework (compiled against 4.5.2 but deployed against 4.8). It is WCF based and the jump to Core was a massive break. But in the end, I think the break was a good decision. There were just too many design mistakes, bad assumptions and underlying system changes to keep compat across the big leap to a modern multi-platform framework. .NET today is faster, more flexible and has more capabilities than .NET Framework ever did. Even if it did take a long time to get here.
And besides, even if new features are not coming to .NET Framework anymore, Microsoft has support .NET 3.5.1 until 2029! [2] Isn't 22 years of support enough? (.NET 4.8's EOL hasn't even been announced yet!)
For writing excel formulas, while I think you can use VSTO/COM, you will get a poor performance if you do. The "right" way to do it is with ExcelDNA/ManagedXLL. But the excel calculation engine was never designed to support async/await, and your calculations operate within a UI thread. So if you need to make a network call in one of your excel functions, you quickly run out of options.
My favorite part about the FOGBANK story is that once they figured out how to manufacture it again, the new version of the material was more chemically pure than the old version, but this actually made the material LESS effective, so they had to add spcific impruities back into it to make it work correctly.
Conceptually they are almost identical, though Virgil has explicit source syntax for making a subrange. One important difference, according to [1] Span<T> can only live on the stack. There are no lifetime restrictions for Range<T> in Virgil.
The methodology helps focus the attention of human labelers on the controversial/borderline cases, making them more effective in how they spend thier time.
If you look at Garnet's source code it is very non-idiomatic C#. It goes to extraordinary lengths to avoid the garbage collector. Almost all memory management is done with unmanaged memory and pointers.
They also have a very clever internal design and do some other tricks like strategically avoiding async/await and moving I/O operations onto the network request thread.
That doesn't make it ok or less impactful. He's been running MyNoise for years and it sounds like if he had been attacked before, this one was much worse, prompting a blog post about it.
You are correct but although the B52 can technically carry the GBU-57 MOP, but it was only done that way during the initial testing of the weapon. The B2 is the only aircraft the USAF actually uses for that munition in combat scenarios.
Also the B2 is better suited for extreme endurance missions like this where the plane is in flight for >36 hours. It has a toilet, microwave and a cot for the pilots to use during the more mundane parts of the mission.
No real secret sauce, the weapon weighs almost 30,000lbs and most of it is just hardened metal to make it heavy. The warhead is only ~5,300lbs of explosive
The kinetics matter here. The B2 flies much higher than the C-130 which would aid the GBU-57 MOP (almost certainly used here) in it's ability to penetrate to maximum depth. 80% of the 15 ton weight of that bomb is just heavy metal to give it maximum energy as it borrows into the ground.
Also, each B2 can carry 2 MOPs making it a better platform than a C-130, and that isn't even taking the stealth of the platform into account
Last time I did excel interop it was COM based and there wasn't any async part of it. I'm curious if you were using COM interop also? Also, async/await was explicitly designed to work in UI contexts like Winforms and WPF where there is only a single UI thread...?
> It took like 15 years before they added a json serializer to the standard library..
That isn't really true. DataContractJsonSerializer [0] landed in .NET 3.5 which was in 2007. Admittedly, it kinda sucked but it was there and was usable. And also JSON.Net was around by that point and was/is excellent.
> ...and don't even think about support for any new major image format (webp, heic).
Image support on windows was historically provided by WIC [1] and does support the formats you talked about. But you are correct that native .NET support for many image formats is non-existent.
> And because they broke backward compatibility on so many libraries, it's a non trivial effort to convert a complex code base to core.
This is very true, and I felt it firsthand. My employer still has a codebase on .NET Framework (compiled against 4.5.2 but deployed against 4.8). It is WCF based and the jump to Core was a massive break. But in the end, I think the break was a good decision. There were just too many design mistakes, bad assumptions and underlying system changes to keep compat across the big leap to a modern multi-platform framework. .NET today is faster, more flexible and has more capabilities than .NET Framework ever did. Even if it did take a long time to get here.
And besides, even if new features are not coming to .NET Framework anymore, Microsoft has support .NET 3.5.1 until 2029! [2] Isn't 22 years of support enough? (.NET 4.8's EOL hasn't even been announced yet!)
[0] https://learn.microsoft.com/en-us/dotnet/api/system.runtime.... [1] https://learn.microsoft.com/en-us/windows/win32/wic/native-w... [2] https://learn.microsoft.com/en-us/lifecycle/products/microso...
reply