3 ms·
I drop the .NET ecosystem long time ago. F# make me look at it, and mostly, the opportunity to use it on OSX/Linux/iOS. I'm uninterested in C#; so I'm trying t
by mamcx 11y ago
I drop the .NET ecosystem long time ago. F# make me look at it, and mostly, the opportunity to use it on OSX/Linux/iOS.
I'm uninterested in C#; so I'm trying to make the case for F# (and to be more brutal: And work good enough under OSX, because all my dev work is on it; plus looking to do iOS dev with F#: That is harder than I was expecting!).
I like the language, not as much as python/pascal but is great enough. I'm toying to build a compiler, and building some utils and porting (ie: experimenting ;) ) a massive obj-c project.
So far, my only gripe, is the extremely weak support for any other database that is not Sql Server. No F# native ORM work on OSX as-is. Sql Type-providers neither. You can make some basic stuff and crash faster after you try anything barely complex, like do a search ;)
I was forced to use NServiceKit (a clone of ServiceKit before go commercial) because was the one that I made to work, but then is made in C# and it break the expectations I was having with F# (like https://stackoverflow.com/questions/31866227/why-im-getting-null-for-a-string-in-f/31885583#31885583 https://stackoverflow.com/questions/31866227/why-im-getting-...)
So, that is my 5-cents: Expect pain outside VS/Sql Server, and I'm not fully convinced on the Web story neither (ie: Nothing as great + simple as django or flask on python)
- yareally 11y ago> No F# native ORM work on OSX as-is. Sql Type-providers neither. You can make some basic stuff and crash faster after you try anything barely complex, like do a search ;) There exists a very good ADO.net wrapper for F# called FsSQL https://github.com/mausch/FsSql https://github.com/mausch/FsSql Dapper can also be used with F#: https://gist.github.com/vbfox/1e9f42f6dcdd9efd6660 https://gist.github.com/vbfox/1e9f42f6dcdd9efd6660 Neither are true ORM compared to say nHibernate, but both include mapping to .net collections. I generally prefer this approach over a true ORM for flexibility.