Skip to content

Conversation

@isaacabraham
Copy link
Contributor

Unless the project does not work in F#.

Unless the project does not work in F#.
@samsp-msft
Copy link
Contributor

Hmm. This project is not intended to be a perfect multi-language solution - being able to use F# or VB to customize the proxy are not explicit goals, and I don't think we have any demand for it from the customers we have spoken to.
My concern here is in terms of expectation setting - we don't explicitly intend to disable non c# languages - but we are not going to explicitly test them either.

@forki
Copy link

forki commented Apr 23, 2020

maybe you have spoken to the wrong customers then? ASP.NET Core is pretty popular in F# land

@isaacabraham
Copy link
Contributor Author

@samsp-msft appreciate your honesty there.

Perhaps try looking at it from another perspective: if someone is looking at adopting F# (and subsequently dotnet) and looks at this project, would you want them to try it out - maybe start using it? Or go away with the impression that this library is only compatible with C#? This is something we see happening more than you might think.

If this is indeed going to be a library that's going to become a part of the asp .net family of packages, it would be unfortunate if people got the wrong idea that ASP .NET = C# only.

@dustinmoris
Copy link

Please don't make me have to create "Pony - A functional wrapper for YARP".

I've got no time for that atm :P

@samsp-msft samsp-msft merged commit 9dbb4a2 into dotnet:master Apr 23, 2020
@samsp-msft
Copy link
Contributor

My hesitancy was from an expectation management perspective. We are not trying to exclude F# or VB, and we don't think that there is anything that will prevent usage of those languages - but creating templates, doing testing etc to have a really welcoming experience for the F# user is not in our short term roadmap.

@isaacabraham isaacabraham deleted the patch-1 branch April 23, 2020 21:56
@isaacabraham
Copy link
Contributor Author

@samsp-msft understood :-) I think no one in the F#-specific userbase will expect some custom F# wrapper for this (of course, that would be lovely!). People will create their own if needed; F# can interop with standard C# pretty well when you need to.

@nbevans
Copy link

nbevans commented Apr 24, 2020

Lack of templates/sample code is not a deterrent since F# developers can almost always read C# code fluently and repurpose it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants