Why on earth did they decide boxing by default was a sensible design decision...
We have been pushing toward higher performance for years and this is a performance pitfall for unions would are often thought of as being lighter weight than inheritance hierarchies.
F# just stores a field-per-case, with the optimization that cases with the same type are unified which is still type safe.
Hi there! One of the C# language designers here, working on unions. All the different options have tradeoffs. As an example, the non-boxing options tear, which can be problematic. And, we have a lot of experience implementing the simple, reference-type, approach for types that make a lot of sense to people, but then adding a lightweight, value-type version for people who care about that later. See tuples, as well as records.
I expect the same will old here. But given the former group is multiple orders of magnitude higher than the latter, we tend to design the language in that order accordingly.
Trust me, we're very intersted in the low-overhead space as well. But it will be for more advanced users that can accept the tradeoffs involved.
And, in the meantime, we're designing it in C#15 that you can always roll the perfect implementation for your use case, and still be thought of as a union from teh language.
From what I've read, this is for the first implementation of unions, to reduce amount of compiler work they need to do. They have designed them in a way they can implement enhancements like this in the future. Things like non-boxing unions and tagged unions / enhanced enums are still being considered, just not for this version.
This is the general pattern of how the C# team operates, IME.
"Never let perfect be the enemy of good"
Very much what I've seen from them over the years as they iterate and improve features and propagate it through the platform. AOT as an example; they ship the feature first and then incrementally move first party packages over to support it. Runtime `async` is another example.
Active patterns, computation expressions, structural typing, statically resolved type parameters, explicit inlining, function composition, structural equality, custom operators and much richer generators.
I understand this is an attack, but I find myself mildly concerned that the model is "aware" enough to behave differently in the assumed context of a alignment test. Isn't this an inherent thread of dishonesty?
I get excited every time I see a paper from Bradish. I've learned so much about high performance software from studying systems that he has worked on. (not to diminish his many co-authors and contributors)
I’ve only played with it at scale and haven’t had the balls to do production with it. We are still heavily reliant on our k8s stack but I want to go bare metal with Orleans.
The Tree of Life is singular to me as a piece of cinema, americana and a meditation on the beauty of life and especially childhood.
When I saw it the first time, I was so awestruck by the breathtaking cinematography and the incredible music, but even more so by the vision of it all. I had simply never seen anything like it.
Yes, the primary reason being the bootstrapping problem. But because Dafny can already can generate C# code, that should not be a major problem. It also allows for a gradual conversion where more and more parts are generated from Dagny sources.
I know that maintaining a compiler in its own language poses some problems when you want to extend that language with additional features.
Because compilers are rather complex problems, they can be viewed as a testing stone for a language.
I think it would be nice to have a formally verified compiler. That is a bit more than proving that the sources are correct. But because formally verified compilers are rare, it could promote the usages of Dayne.
I am aware that it would be quite an effort to make it self-hosted and even more to formally verify it correctness.
> 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.
We have been pushing toward higher performance for years and this is a performance pitfall for unions would are often thought of as being lighter weight than inheritance hierarchies.
F# just stores a field-per-case, with the optimization that cases with the same type are unified which is still type safe.
reply