Ivan Kashtanov
@0costdistraction.bsky.social
.NET/Angular developer
Same goes for DateOnly/TimeOnly: afterthoughts that still feel clunky to switch to because now we have so many people and APIs e.g. expecting DateTime's Date to also be a DateTime that proper introduction just feels impossible. Proper date/time arithmetic is also just not there.
November 29, 2025 at 7:20 AM
Same goes for DateOnly/TimeOnly: afterthoughts that still feel clunky to switch to because now we have so many people and APIs e.g. expecting DateTime's Date to also be a DateTime that proper introduction just feels impossible. Proper date/time arithmetic is also just not there.
TimeProvider was released in .NET 8(!) and still it's a quest to convince other developers to switch to it (two decades of habits, what can we do). And its Windows-specific timezone ID shenanigans only add to the chaos of switching to it.
November 29, 2025 at 7:16 AM
TimeProvider was released in .NET 8(!) and still it's a quest to convince other developers to switch to it (two decades of habits, what can we do). And its Windows-specific timezone ID shenanigans only add to the chaos of switching to it.
Case in point: date/time. NodaTime has been around for ages, and while JodaTime became that accepted standard ad JSR 310 was a way to co-opt it with minimal effort, .NET developers are largely holding onto their DateTime.UtcNow.
November 29, 2025 at 7:13 AM
Case in point: date/time. NodaTime has been around for ages, and while JodaTime became that accepted standard ad JSR 310 was a way to co-opt it with minimal effort, .NET developers are largely holding onto their DateTime.UtcNow.
Java has Spring as a dominant trendsetter and stuff like JSpecify which is steered by multiple major players.
Scala has Typelevel but ultimaltely the approach there is "language provides core concepts, libraries make use of it".
.NET ecosystem is de-facto steered by whatever MS provides.
Scala has Typelevel but ultimaltely the approach there is "language provides core concepts, libraries make use of it".
.NET ecosystem is de-facto steered by whatever MS provides.
November 29, 2025 at 7:10 AM
Java has Spring as a dominant trendsetter and stuff like JSpecify which is steered by multiple major players.
Scala has Typelevel but ultimaltely the approach there is "language provides core concepts, libraries make use of it".
.NET ecosystem is de-facto steered by whatever MS provides.
Scala has Typelevel but ultimaltely the approach there is "language provides core concepts, libraries make use of it".
.NET ecosystem is de-facto steered by whatever MS provides.
It may be a nice thing to use in things unde your direct control but once you try this in enterprise projects it's a risky endeavour. If it's an edge dependency like FluentAssertions, you're lucky. But introducing the core stuff and then hitting that risk would be much worse.
November 29, 2025 at 7:05 AM
It may be a nice thing to use in things unde your direct control but once you try this in enterprise projects it's a risky endeavour. If it's an edge dependency like FluentAssertions, you're lucky. But introducing the core stuff and then hitting that risk would be much worse.
I strongly believe that the "core" concepts should be either a part of a language/BCL or a de-facto accepted standard. Otherwise you get a dependency that spreads through your whole codebase and ties you to it.
November 29, 2025 at 7:02 AM
I strongly believe that the "core" concepts should be either a part of a language/BCL or a de-facto accepted standard. Otherwise you get a dependency that spreads through your whole codebase and ties you to it.
In concusion: you can certainly introduce "classic" functional concepts in your codebase but to me it always feels like I'm dealing with half-baked ad-hoc features for specific use cases that give you no choice but to accept compromising solutions.
November 27, 2025 at 8:13 PM
In concusion: you can certainly introduce "classic" functional concepts in your codebase but to me it always feels like I'm dealing with half-baked ad-hoc features for specific use cases that give you no choice but to accept compromising solutions.
I'd add a point about the most recommended DI practices e.g. MS DI or Autofac which IMO also don't have anything "FP"-centric in them, good old injection and dynamic dependency resolution.
November 27, 2025 at 8:10 PM
I'd add a point about the most recommended DI practices e.g. MS DI or Autofac which IMO also don't have anything "FP"-centric in them, good old injection and dynamic dependency resolution.
ErrorOr etc. provide even simpler abstractions with even more unclear advantages. Ok, you have a Result type.
- "Third-party" problem is still there.
- Further improvements (readable chaining, for one) are just not there for most.
Partial implementations of a cohesive set of capabilities.
- "Third-party" problem is still there.
- Further improvements (readable chaining, for one) are just not there for most.
Partial implementations of a cohesive set of capabilities.
November 27, 2025 at 7:59 PM
ErrorOr etc. provide even simpler abstractions with even more unclear advantages. Ok, you have a Result type.
- "Third-party" problem is still there.
- Further improvements (readable chaining, for one) are just not there for most.
Partial implementations of a cohesive set of capabilities.
- "Third-party" problem is still there.
- Further improvements (readable chaining, for one) are just not there for most.
Partial implementations of a cohesive set of capabilities.
Secondly, the current version of HKTs there are fascinating but mind-crunching. And since people often choose C# for familiarity and perceived clarity, it's difficult to make these higher-level concepts to take root and spread.
November 27, 2025 at 7:56 PM
Secondly, the current version of HKTs there are fascinating but mind-crunching. And since people often choose C# for familiarity and perceived clarity, it's difficult to make these higher-level concepts to take root and spread.
There's LanguageExt with giant amount of effort put into making a third-party library going as close as possible for the points 2 and 3, but it's a third-party library with commercial licensing, justification for using it would be a nightmare (even stuff like NodaTime is not a de-facto standard)
November 27, 2025 at 7:49 PM
There's LanguageExt with giant amount of effort put into making a third-party library going as close as possible for the points 2 and 3, but it's a third-party library with commercial licensing, justification for using it would be a nightmare (even stuff like NodaTime is not a de-facto standard)
Depends on your definition of FP style (and on how widely accepted that defintion is).
Nominal union types (ADTs and exhaustive matching): planned but no reliable schedule.
"Typeclasses" (extensions implementing interfaces): same.
HKTs: good luck with that.
Nominal union types (ADTs and exhaustive matching): planned but no reliable schedule.
"Typeclasses" (extensions implementing interfaces): same.
HKTs: good luck with that.
November 27, 2025 at 7:45 PM
Depends on your definition of FP style (and on how widely accepted that defintion is).
Nominal union types (ADTs and exhaustive matching): planned but no reliable schedule.
"Typeclasses" (extensions implementing interfaces): same.
HKTs: good luck with that.
Nominal union types (ADTs and exhaustive matching): planned but no reliable schedule.
"Typeclasses" (extensions implementing interfaces): same.
HKTs: good luck with that.
There's also a presentation for the demo github.com/binarybang/f...
github.com
November 7, 2025 at 9:29 PM
There's also a presentation for the demo github.com/binarybang/f...
In additiona, FluentAssertions' influence is tangential: it doesn't touch any deep layers and can be replaced easily.
Imagine a core-level library like NodaTime going the same way. Sure, rights and everything, but the impact on the platform would be anything but positive.
Imagine a core-level library like NodaTime going the same way. Sure, rights and everything, but the impact on the platform would be anything but positive.
February 23, 2025 at 2:44 PM
In additiona, FluentAssertions' influence is tangential: it doesn't touch any deep layers and can be replaced easily.
Imagine a core-level library like NodaTime going the same way. Sure, rights and everything, but the impact on the platform would be anything but positive.
Imagine a core-level library like NodaTime going the same way. Sure, rights and everything, but the impact on the platform would be anything but positive.
Yes, it's obviously my opinion. What else would I write?
And, of course, he has that right. The question is how much the history of exercising those rights should affect potential consumers' decisions. Architect's position doesn't imply fiduciary duty but a dependency like this may be problematic.
And, of course, he has that right. The question is how much the history of exercising those rights should affect potential consumers' decisions. Architect's position doesn't imply fiduciary duty but a dependency like this may be problematic.
February 23, 2025 at 2:41 PM
Yes, it's obviously my opinion. What else would I write?
And, of course, he has that right. The question is how much the history of exercising those rights should affect potential consumers' decisions. Architect's position doesn't imply fiduciary duty but a dependency like this may be problematic.
And, of course, he has that right. The question is how much the history of exercising those rights should affect potential consumers' decisions. Architect's position doesn't imply fiduciary duty but a dependency like this may be problematic.
- The way async validation works there seems unclear to me for now
- I can't see how common declarative use of valueChanges with debounce and async data retrieval (e.g. autocomplete) works here (I see that FormGroup is not the Angular one but a separate implementation)
- I can't see how common declarative use of valueChanges with debounce and async data retrieval (e.g. autocomplete) works here (I see that FormGroup is not the Angular one but a separate implementation)
February 6, 2025 at 5:59 PM
- The way async validation works there seems unclear to me for now
- I can't see how common declarative use of valueChanges with debounce and async data retrieval (e.g. autocomplete) works here (I see that FormGroup is not the Angular one but a separate implementation)
- I can't see how common declarative use of valueChanges with debounce and async data retrieval (e.g. autocomplete) works here (I see that FormGroup is not the Angular one but a separate implementation)
Conclusion (sort of): the original blog post does mention an important concept but the real-world application of it will be significantly different.
For a learner it's a good piece of food for thought but don't forget to consider the actual functional requirements when you remember it later.
For a learner it's a good piece of food for thought but don't forget to consider the actual functional requirements when you remember it later.
February 1, 2025 at 4:58 PM
Conclusion (sort of): the original blog post does mention an important concept but the real-world application of it will be significantly different.
For a learner it's a good piece of food for thought but don't forget to consider the actual functional requirements when you remember it later.
For a learner it's a good piece of food for thought but don't forget to consider the actual functional requirements when you remember it later.
There is a somewhat related discussion (bsky.app/profile/ravi...) about how much variety should there be in .NET ecosystem but in any case, this would stay a secondary concern in the proposed structure.
.NET Developers Begging for Ecosystem Destruction by Aaron Stannard is a good read.
aaronstannard.com/dotnet-event...
aaronstannard.com/dotnet-event...
.NET Developers Begging for Ecosystem Destruction
Cheering for the destruction of options because...?
aaronstannard.com
February 1, 2025 at 4:58 PM
There is a somewhat related discussion (bsky.app/profile/ravi...) about how much variety should there be in .NET ecosystem but in any case, this would stay a secondary concern in the proposed structure.
Now about the tactical part.
While we can add a custom output caching implementation for ASP.NET Core APIs, the real-world application would probably use OutputCaching/ResponseCaching with some custom caching policy.
No custom implementation from scratch - less code to maintain.
While we can add a custom output caching implementation for ASP.NET Core APIs, the real-world application would probably use OutputCaching/ResponseCaching with some custom caching policy.
No custom implementation from scratch - less code to maintain.
February 1, 2025 at 4:57 PM
Now about the tactical part.
While we can add a custom output caching implementation for ASP.NET Core APIs, the real-world application would probably use OutputCaching/ResponseCaching with some custom caching policy.
No custom implementation from scratch - less code to maintain.
While we can add a custom output caching implementation for ASP.NET Core APIs, the real-world application would probably use OutputCaching/ResponseCaching with some custom caching policy.
No custom implementation from scratch - less code to maintain.
I guess this is more useful to long-living systems which grow over time to handle multiple data sources and integrations.
I'd argue though that as a product developer, one should consider these thoughts at the start while the system is flexible enough to bend as needed with minimal effort.
I'd argue though that as a product developer, one should consider these thoughts at the start while the system is flexible enough to bend as needed with minimal effort.
February 1, 2025 at 4:57 PM
I guess this is more useful to long-living systems which grow over time to handle multiple data sources and integrations.
I'd argue though that as a product developer, one should consider these thoughts at the start while the system is flexible enough to bend as needed with minimal effort.
I'd argue though that as a product developer, one should consider these thoughts at the start while the system is flexible enough to bend as needed with minimal effort.