2 ms·

Every time I give F# a chance in production I get burned. A couple of weeks ago I needed to write some data sync code between some spreadsheets, asset folders a

Every time I give F# a chance in production I get burned. A couple of weeks ago I needed to write some data sync code between some spreadsheets, asset folders and a database. A perfect scenario for a simple F# script - I'll use type providers and have the entire thing type safe and done in one file. Turns out type providers are the most brittle shit feature ever and getting it working in a CI/CD build without access to the resources is a major PITA. After wasting a day mucking around with useless tech I just wrote a C# CLI app next morning and moved on with my life. Other scenarios I've seen it fail : - enthusiastic team members try to push it, leave the company and nobody wants to touch that anymore - tooling support being garbage - worked on a project where you had to disable F# projects just to get intellisense working - second class citizen everywhere - using rider right now and C# experience is > VS (IMO), meanwhile while working on this script found one or two "not supported yet" scenarios and code analysis died randomly through using it (probably type providers) At the end of the day C# added records, switch expression gets me pretty far, global usings and file scoped namespaces - it cut down on boilerplate and noise, it gives me most of the F# benefits while being well supported and widespread.

JamesSwift 4y ago
I also tried to get into F# and was turned off by really confusing type provider issues that I dont believe I ever figured out. I'll have to give it another go, but it wasn't a great first impression and C# is in a pretty good spot overall right now.
- Eji1700 4y ago
  I'll say what I said to the other comment. Skip type providers. They're a neat concept but much like inheritance their use case winds up being massively more narrow that you'd first think. The main draws are functions as a first class citizen (with a light syntax for that), low boiler plate, type inference with strong typing, and immutable by default. Oh and I also like the top down coding structure. The amount of runtime errors i have in F# is minimal (generally because you're connecting to something wrong), because so much is caught in the compiler. Debugging is usually cake, and you're not afraid to really abstract out your code and start passing around functions because the syntax is light and easy.
celdon25 4y ago
> using rider right now and C# experience is > VS (IMO), meanwhile while working on this script found one or two "not supported yet" scenarios and code analysis died randomly through using it (probably type providers) Jetbrains is the new company practicing “embrace, extend, extinguish”. They royally screwed up the implementation of YARD macros in Rubymine. Their F# IDE launch was a technical failure as well. Never had any of those problems with Visual Studio.
Eji1700 4y ago
I'll say this, I think type providers are somewhat of a trap. Not quite as much of an oops as inheritance, but their use case isn't quite what it gets sold as. The best use i've seen of them is for quick, run once to get something, scripts where you're briefly connecting to a complicated dataset and want to rip some data out and do something with it. As a long standing production tool.....i feel like you wind up running into enough issues with trying to adapt it to data changes that you're just better off not using it in the first place. As for team members pushing it and leaving...well that's an issue with just about any language adoption, good or bad. We'd all still be on C++ if some people hadn't bothered to learn new toys. Tooling...i dunno. I've never had something that severe but it's second classness shows. I use vs code/vs and its MOSTLY great, but there's some WEIRD shit that can happen for sure, There's no doubt C# is more supported than F# and it's a shame because that'll always remain the case, but F# can work on top of C# very well (not so much the other way). I really do see type providers as almost near inheritance though in the "oh this is cool until you use it and realize it's not". The main draws for me are that it's super easy to set up errorless models with types/records/etc and it's very low boilerplate while still actually having strong typing and immutable by default.

JamesSwift 4y ago

I also tried to get into F# and was turned off by really confusing type provider issues that I dont believe I ever figured out. I'll have to give it another go, but it wasn't a great first impression and C# is in a pretty good spot overall right now.

Eji1700 4y ago
I'll say what I said to the other comment. Skip type providers. They're a neat concept but much like inheritance their use case winds up being massively more narrow that you'd first think. The main draws are functions as a first class citizen (with a light syntax for that), low boiler plate, type inference with strong typing, and immutable by default. Oh and I also like the top down coding structure. The amount of runtime errors i have in F# is minimal (generally because you're connecting to something wrong), because so much is caught in the compiler. Debugging is usually cake, and you're not afraid to really abstract out your code and start passing around functions because the syntax is light and easy.

celdon25 4y ago

> using rider right now and C# experience is > VS (IMO), meanwhile while working on this script found one or two "not supported yet" scenarios and code analysis died randomly through using it (probably type providers) Jetbrains is the new company practicing “embrace, extend, extinguish”. They royally screwed up the implementation of YARD macros in Rubymine. Their F# IDE launch was a technical failure as well. Never had any of those problems with Visual Studio.

Eji1700 4y ago

I'll say this, I think type providers are somewhat of a trap. Not quite as much of an oops as inheritance, but their use case isn't quite what it gets sold as. The best use i've seen of them is for quick, run once to get something, scripts where you're briefly connecting to a complicated dataset and want to rip some data out and do something with it. As a long standing production tool.....i feel like you wind up running into enough issues with trying to adapt it to data changes that you're just better off not using it in the first place. As for team members pushing it and leaving...well that's an issue with just about any language adoption, good or bad. We'd all still be on C++ if some people hadn't bothered to learn new toys. Tooling...i dunno. I've never had something that severe but it's second classness shows. I use vs code/vs and its MOSTLY great, but there's some WEIRD shit that can happen for sure, There's no doubt C# is more supported than F# and it's a shame because that'll always remain the case, but F# can work on top of C# very well (not so much the other way). I really do see type providers as almost near inheritance though in the "oh this is cool until you use it and realize it's not". The main draws for me are that it's super easy to set up errorless models with types/records/etc and it's very low boilerplate while still actually having strong typing and immutable by default.