You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sorry I can't stand this.
Considering leaving F# on this global move.
Thank you for what you've done, but I think this is taking a very harmful direction.
@thinkbeforecoding Happy to talk about it, would you like to? Ping me on Slack?
Use is limited to very stale repos with technical debt that needs clearing, or where active maintainers want this. If there has been no activity for years and there are 100s of bugs it really is best to clear them out. And this is by far the most efficient way to do that that I'm aware of.
Yes, you know I have a great respect for your work on F#, but I'm really disappointed.
I'd be also happy to talk about it.
I don't use much slack any more, but i'll drop you a message to discuss.
@thinkbeforecoding By all means contact me on email - donsyme at fastmail com. Would be happy to have a zoom call, would be lovely to catch up with you in any case.
I sent you a link to my nextcloud talk instance so we can take time to discuss. :)
Of course, we can do it also another day, if it's not the right time for you.
I think most of the F# open-source "issues" aren't real issues. Most of these are ideas from the past that the libraries never took on; they haven't been closed, but they are not critical to library users. The components seem to work absolutely fine, and the "stale" is just because there is nothing to fix.
Now, there are dependencies, and keeping up to date with the latest version is a form of technical debt, is it? For example, .NET releases a major version every year, while Stripe.NET seems to update 2 times a week. Is it a technical debt that you don't update your software twice a week when someone renames items from InvoiceSum to Invoice.Sum and then back to InvoiceSum? I think that's acceptable "technical debt".
I was full-time working on the F# stack a year ago. The company had 5 developers maintaining a codebase of 750k registered customers and hundreds of thousands of payments. The type providers were the main reason we could operate with such a small headcount. We did use SwaggerProvider for around 5-10 financial APIs and FSharp.Data to around 10-15 financial APIs. SwaggerProvider doesn't work for every API because it expects the schema to be in good shape, but in real life, OpenAPI schemas are not always correct, or even contradict the behaviour of the actual APIs. Then you fallback to FSharp.Data JsonProvider. But when SwaggerProvider worked, it worked; there were absolutely no issues. Once integrated, the maintenance could be forgotten until a major business-direction shift occurs. The same with FSharp.Data and SQLProvider, once they are set up, are amazing products. I would have had more time to contribute to OSS software development, but all the tools were working so well that there wasn't anything urgent to contribute to.
It's true .NET + F# + FSharp.Data + Fable + ... gives a very solid foundation.
I've been through the FSharp.Data issues and have been very glad to fix or close them out. There were real bugs for sure, reported long ago and repeatedly hit, but partly about obscure JSON/Floating point numeric things.
There were also missing features (e.g. DateTimeOffset support, DateOnly and various static type provider parameters) which were simple enough for a modern coding agent to implement.
What matters to me is to "complete the picture" on this kind of library/tool. That is
Fix the bugs
Fill in the holes that are obvious missing pieces especially if reported by users
Keep it up to date in engineering
Close out questions
Investigate obvious performance black holes if reported
Make sure releases can be made
The thing is, all of these are routine things to do with a coding agent today. So if a user reports a bug with NaNs and JSON then for sure the first thing any maintainer is going to do is asking a coding agent to do a depth investigation of the problem and report back.
That's really what Repo Assist is for. Do the obvious, basic investigations with a coding agent, proactively, and mine the backlog and get things stable and clean.
I think we have a future where all our repos have like 10-20 open enhancement suggestions at most. There's really no need to have bugs in these components anymore. As an example, FSharp.Formatting is now down to 20 issues, with lots of real bugs fixed. I'm happy for that https://github.com/fsprojects/FSharp.Formatting/issues.
Activity
sergey-tihon commentedon Mar 7, 2026
Yes,please. Very interesting
dsyme commentedon Mar 8, 2026
Added! I set it to once per day, will run a blast of 5 days worth to start
thinkbeforecoding commentedon Mar 8, 2026
Sorry I can't stand this.
Considering leaving F# on this global move.
Thank you for what you've done, but I think this is taking a very harmful direction.
dsyme commentedon Mar 8, 2026
@thinkbeforecoding Happy to talk about it, would you like to? Ping me on Slack?
Use is limited to very stale repos with technical debt that needs clearing, or where active maintainers want this. If there has been no activity for years and there are 100s of bugs it really is best to clear them out. And this is by far the most efficient way to do that that I'm aware of.
thinkbeforecoding commentedon Mar 8, 2026
Yes, you know I have a great respect for your work on F#, but I'm really disappointed.
I'd be also happy to talk about it.
I don't use much slack any more, but i'll drop you a message to discuss.
dsyme commentedon Mar 8, 2026
@thinkbeforecoding By all means contact me on email - donsyme at fastmail com. Would be happy to have a zoom call, would be lovely to catch up with you in any case.
dsyme commentedon Mar 8, 2026
@sergey-tihon First added unit tests are here: #295
thinkbeforecoding commentedon Mar 8, 2026
I sent you a link to my nextcloud talk instance so we can take time to discuss. :)
Of course, we can do it also another day, if it's not the right time for you.
Thorium commentedon Mar 9, 2026
I think most of the F# open-source "issues" aren't real issues. Most of these are ideas from the past that the libraries never took on; they haven't been closed, but they are not critical to library users. The components seem to work absolutely fine, and the "stale" is just because there is nothing to fix.
Now, there are dependencies, and keeping up to date with the latest version is a form of technical debt, is it? For example, .NET releases a major version every year, while Stripe.NET seems to update 2 times a week. Is it a technical debt that you don't update your software twice a week when someone renames items from InvoiceSum to Invoice.Sum and then back to InvoiceSum? I think that's acceptable "technical debt".
I was full-time working on the F# stack a year ago. The company had 5 developers maintaining a codebase of 750k registered customers and hundreds of thousands of payments. The type providers were the main reason we could operate with such a small headcount. We did use SwaggerProvider for around 5-10 financial APIs and FSharp.Data to around 10-15 financial APIs. SwaggerProvider doesn't work for every API because it expects the schema to be in good shape, but in real life, OpenAPI schemas are not always correct, or even contradict the behaviour of the actual APIs. Then you fallback to FSharp.Data JsonProvider. But when SwaggerProvider worked, it worked; there were absolutely no issues. Once integrated, the maintenance could be forgotten until a major business-direction shift occurs. The same with FSharp.Data and SQLProvider, once they are set up, are amazing products. I would have had more time to contribute to OSS software development, but all the tools were working so well that there wasn't anything urgent to contribute to.
dsyme commentedon Mar 9, 2026
It's true .NET + F# + FSharp.Data + Fable + ... gives a very solid foundation.
I've been through the FSharp.Data issues and have been very glad to fix or close them out. There were real bugs for sure, reported long ago and repeatedly hit, but partly about obscure JSON/Floating point numeric things.
There were also missing features (e.g. DateTimeOffset support, DateOnly and various static type provider parameters) which were simple enough for a modern coding agent to implement.
What matters to me is to "complete the picture" on this kind of library/tool. That is
The thing is, all of these are routine things to do with a coding agent today. So if a user reports a bug with NaNs and JSON then for sure the first thing any maintainer is going to do is asking a coding agent to do a depth investigation of the problem and report back.
That's really what Repo Assist is for. Do the obvious, basic investigations with a coding agent, proactively, and mine the backlog and get things stable and clean.
I think we have a future where all our repos have like 10-20 open enhancement suggestions at most. There's really no need to have bugs in these components anymore. As an example, FSharp.Formatting is now down to 20 issues, with lots of real bugs fixed. I'm happy for that https://github.com/fsprojects/FSharp.Formatting/issues.