8 ms·
Get Started with F# as a C# developer
- marvel_boy 9y agoNewbie here. Somebody can point to useful other resources for F#?
- voqk 9y agohttps://fsharpforfunandprofit.com/ https://fsharpforfunandprofit.com/
- oxryly1 9y agohttps://fsharpforfunandprofit.com https://fsharpforfunandprofit.com is great. I'm enjoying Don Syme's book "Expert F# 4.0" as well.
- JamesBarney 9y agoThis website if one of the best I've read, and I recommend it even if you have no interest in F#. I learned more about how to write OOP and think about types than years of reading other blogs.
- kzisme 9y agoIs there a really good reason to choose to use F# over C#? Or does it really just come down to preference?
- mookid11 9y agoIt depends if you enjoy NullPointerExceptions.
- sremani 9y agoThe returns on choosing F# are very much reliant of level of proficiency attained. Once you are proficient, you will write - less code for similar functionality - have lot less dependency cycles - using Option types over null helps in the long run - improvement in productivity The only problem is that you have attain a level of proficiency and flip the "train" of thought from OOP to Functional, and that can take some good time.
- kzisme 9y agoGotcha - thanks! I haven't touched functional languages other than for fun lately, so I may take a look sooner or later. I've always been interested.
- jackmott 9y agopros: less typing less null pointer exceptions cons: performance (doesn't have to be bad but if you do things idiomatically will tend to be) tooling and other externalities (better that most niche languages but not as good as c#)
- wyoung2 9y agoJust to add to what the others have said: 1. Immutable values by default avoids whole categories of problems. Just for one example, you can't have a data race between two threads if all the public values accessible from each thread are guaranteed immutable. 2. F# forces all cases to be handled. You've doubtless run into C# code that has a switch statement that doesn't have cases for all possible inputs, and no default case. F# doesn't have a direct equivalent of "switch" at all, but it does enforce completeness in the equivalents it does have. For example, it's illegal in F# to say something like "if foo > 1 then ... elif foo < 1 ..." since that leaves the 0 case unhandled. This is not just about better compiler warnings: it's required by the very fact that "if/else" is an expression, not a statement, so all branches must produce a value for all inputs. 3. F# has units of measure data types. Ever had an application bug because you've incorrectly passed a bare "int" value holding milliseconds to a function expecting seconds? I have. F# lets you define your units as part of the data type, so that it's a compiler error to pass milliseconds to a function expecting seconds. I could go on, but as you can see, there really are substantial differences in practice between F# and C# code.
- eddof13 9y agoSeconding the f# for fun and profit suggestions, especially the railway oriented programming section, I've also heard the following is good, but I have yet to try them: http://www.fsharpworkshop.com/ http://www.fsharpworkshop.com/ http://products.tamizhvendan.in/fsharp-applied/ http://products.tamizhvendan.in/fsharp-applied/
- rspeele 9y agoIf you are a C# developer you may appreciate these translations I've put together: https://github.com/rspeele/CSharpFSharpPhrasebook https://github.com/rspeele/CSharpFSharpPhrasebook This does not sell the language -- it doesn't show off anything interesting you can do in F# that you can't in C#. There are other resources for "why F#". This is for C# developers who are convinced that they want to learn, but are annoyed by not being able to quickly look up how to do the things that they're familiar with from C#.
- oxryly1 9y agoAsynchronous programming with F# is pretty cool. It has layered powerful syntax and language constructs on top of .NET's threads and tasks, AND it gives you convenient access to the same async API that you use in C#.
- jackmott 9y agoperformance is not good though, if you are trying to use it to leverage multiple cores.
- oxryly1 9y agoIs this because of GC? I just came across this statement on the Hopac site: > Before you begin using Hopac, make sure that you have configured your F# interactive and your application to use server garbage collection. By default, .Net uses single-threaded workstation garbage collection, which makes it impossible for parallel programs to scale.
- GordonS 9y agoI'm a C# dev and recently tried out F#. Async and async workflows/computation expressions were actually one of the things I struggled most with in F#. Can you suggest any good resources for learning more?
- stinos 9y agoAsk HN: I've toyed around with F# and I kinda like it but I've never dug deep enough into it to answer the question: can I use this for 'real life' code as part of an existing C# desktop application for instance, e.g. build some F# into an assembly which is callable from C#? Without tons of hassle? What are good samples of real life application code in F#?
- talyian 9y ago> can I use this for 'real life' code as part of an existing C# desktop application .. without tons of hassle Yes. Your standard OOP features like inheriting from C# classes, implementing interfaces, etc are supported natively in F#. The main hassle in being C#-compatible is exposing an external OOP api with only .NET types and interfaces instead of standard F# types. This means, for example, exposing `seq` (`IEnumerable`) instead of `list` (`Microsoft.FSharp.Collections.List`) or using the struct-tuple construct in F# 4.1 so C# 7 can access it. > good samples of real life application code No personal recommendations but have you seen https://github.com/fsprojects/awesome-fsharp https://github.com/fsprojects/awesome-fsharp
- jackmott 9y agoyes you can. C# / F# interop is not zero hassle but it is low hassle. Most of the time it just works. There are a few features in each language that are not zero hassle, if a C# api uses a custom implicit conversion, calling it from F# requires you to explicitly call the implicit conversion (ha!) and if an F# api returns something F# specific like an Option type, using it in c# can be a pain. At my company we have a C# codebase for a large web application, but we create a 2 stage caching feature for it in F#. This F# project uses a couple of C# oriented libraries (stackexchange.redis and protobuf-net). So lots of interop going both ways. Some examples of people using it in production: http://fsharp.org/testimonials/ http://fsharp.org/testimonials/
- eurg 9y ago> Without tons of hassle? Well, yes and no. You definitely can do this, and for some applications it's worth it, but often the overhead at the API level will make you cringe. APIs designed for C# are very different than APIs designed for F#, to account for partial application of functions, sum-types, non-nullability, immutability and value-like behavior by default from F# types, and also to make good use of F#'s type inference. Also, given stuff like the |> operator, making "fluent" APIs looks very different. Using APIs made explictly for F# from the side of C# is somewhere between enormously annoying and de-facto impossible. The other way 'round, it's just massively annoying, as you lose many advantages of F#, and the code will not be much more compact as if you would write it from C#. Pain-points in practice are around F# functions vs. C# methods and delegates, async/await vs. async-expressions, code quotations vs. Linq expressions, etc. To be productive in F#, you want your API small and primitive, and stay within the language for the rest. If this is possible, go for it; if not, evaluate. A final tip: Porting a big block from C# to F# is much less work than it sounds, and opens the door to refactoring that part into something sensible.
- NicoJuicy 9y agoIf you want to try out f#, don't forget to try it with http://fsharp.github.io/FSharp.Data/ http://fsharp.github.io/FSharp.Data/ It's pretty awesome
- hdhzy 9y agoAre there any simple projects like HTTP server in F# for CoreCLR somewhere? With a Dockerfile if possible. Last time I tried to build something like that for PoC the amount of struggles I had with various versions of CoreCLR was overwhelming.
- sremani 9y agoFreya ? This link may help you, https://www.infoq.com/news/2017/05/freya-kestrel https://www.infoq.com/news/2017/05/freya-kestrel
- kirse 9y agoGiraffe is a fantastic little project that is a thin layer on top of ASP.NET Core. Works out of the box with the provided template, test locally, deploy to Azure, etc. https://github.com/dustinmoris/Giraffe https://github.com/dustinmoris/Giraffe
- hdhzy 9y agoThanks but I'm looking for something simple like returning plain text in 200 HTTP response using only built-in API. Completely minimal example. Using framework for me now would be like learning JavaScript by writing SPA in React.
- kirse 9y agoFSSnip usually has those things. If you're talking that minimal I would just look up existing C# docs and translate them over to F#... ASP.NET Core is very lightweight w/ Kestrel though. [1] http://fssnip.net/7OR/title/Simple-HTTP-Server http://fssnip.net/7OR/title/Simple-HTTP-Server [2] http://fssnip.net/search/http%20server http://fssnip.net/search/http%20server
- hdhzy 9y agoWow, that's exactly what I wanted. Thank you very much! Fssnip looks great.
- GiorgioG 9y agoI'll take MS's commitment to F# seriously when they stop treating it like a 2nd class citizen. .NET Core 1.0 has been out for over a year, .NET Core 2.0 is in preview and there is ZERO support for F# with .NET Core in Visual Studio 2017. Yes you can use VSCode, but VSCode is no Visual Studio - it's a text editor on steroids, not a proper IDE that most C# developers have come to expect.
- louthy 9y agoI agree, it's been a nightmare. I've dropped support for F# from my FOSS project because I can't get the .NET Core build working alongside the C# projects (and packed in a nu-get package, and deployed all in one process). I know that if I try to use it alongside any C# projects I will almost certainly lose many hours of time and it probably will fail to work at all. I don't know how much of this is the F# team's fault, but F# the 'eco-system' feels like it's going backwards at the moment.
- kirse 9y agoF# the 'eco-system' feels like it's going backwards at the moment. As in physics, it's all relative. .NET has been moving so quickly lately that the F# team (from my outside-looking-in view) does not have the resources to keep up. You can see that by how stretched thin they are on GitHub issues. I'd imagine things will eventually stabilize once .NET Core settles in, but that'll be a few years. But you are right, the tradeoff always seems to be "do I want to struggle and learn" or "do I just want to get things done."
- GiorgioG 9y agoIf you want to get things done in .NET Core, use C#. If you want to learn functional programming then sure, use F# and the full .NET Framework...but good luck finding help when you need it because compared to the number of people Elixir, Scala, etc - hardly anyone is using F#. I started learning F#, but ultimately I decided I'd rather learn either Scala or Elixir because they are more "mainstream" functional programming options. If anyone doubts this, compare the number of F# repos to Elixir/Scala on Github. I've voiced my frustration on several Github issues about the fact that F# is understaffed at MS, that F# is a 2nd class citizen to C#, etc - to no avail. It's fine, management at MS makes those calls...but then they shouldn't be surprised that there's no uptake on F#'s usage.
- deleted 9y ago[deleted]
- nullspace 9y ago// Flip the BST using pattern matching! let rec flip bst = match bst with | Empty -> bst | Node(item, left, right) -> Node(item, flip right, flip left) Without type annotations, how can it tell the flip takes an instance of BST as the parameter?
- omaranto 9y agoThe variable bst is something that can be matched with Empty and with Node(item, left, right), both of which are of type BST. When two values can be matched with each other, they must be of the same type. Therefore bst is of type BST too.
- nlawalker 9y agoCan anyone suggest any F# tutorials in the style of Michael Hartl's Rails Tutorial? F# suffers from an overabundance of "getting started" tutorials that focus only on the language and syntax. I get that F# is likely to be a lot of peoples' first introduction to a functional language, so that makes sense, but this one doesn't even tell you how to run the code it's showing you. The hardest part about learning any new language isn't learning the syntax or core concepts, it's understanding the mechanics of actually getting things done - grokking the developer workflow, getting comfortable in an editing environment, building and deploying, troubleshooting and debugging, writing idiomatic code, learning about common libraries and tools, etc.
- matteuan 9y agoI think there is nothing better than the book: Expert F# https://www.amazon.de/Expert-F-4-0-Don-Syme/dp/1484207416/ref=sr_1_1?ie=UTF8&qid=1501264192&sr=8-1&keywords=expert+f%23 https://www.amazon.de/Expert-F-4-0-Don-Syme/dp/1484207416/re...
- nlawalker 9y agoI'm making my way through it now, but it doesn't have quite what I'm looking for. I just found http://fsprojects.github.io/ProjectScaffold/structure.html http://fsprojects.github.io/ProjectScaffold/structure.html, which is a good example of the kind of thing I'm interested in (ProjectScaffold in general, but that page in particular, which actually explains what everything in the project structure is for).
- debacle 9y agoI need to know why to use F#, not how. C# is a business programming language. F# doesn't appear to be obviously useful in that regard.
- addicted 9y agoThe first sentence in that post. "One of our previous posts, Why You Should Use F#, listed a few reasons why F# is worth trying out today" I would argue F# is a much better business programming language than C#. Admittedly, I am not very good at it, and have barely done more than a few toy programs in it, but F# (like most FP languages) allows you to bake in a lot of the rules into the Types themselves, and immutability combined with a lack of nullness protects you from a lot of footguns.
- KurtMueller 9y agoScott Wlaschin's talk does a pretty good job of demonstrating how F# is pretty great for BLOBAs (Boring Line of Business applications). You can find it here: https://fsharpforfunandprofit.com/ddd/ https://fsharpforfunandprofit.com/ddd/
- steego 9y agoI would argue that F# is a better business programming language for a lot of reasons. First, the type system is great when it comes to modeling the problem and communicating that model with non-technical project managers because writing good data models often means you write clear code that's idiosyncratic to the language. My experience is non-technical people understand clear data models and pipelines and those are two areas where F# code reads very clearly. If OOP is your thing, I can argue it's a much better OOP language than C#. From a SOLID and Design Patterns perspective, the language has been streamlined to encourage a good OOP style by default. Design Patterns are simpler (Factory, Builder, Decorator, Adaptor, etc). Dependency Injection is very natural and implementing fluent APIs is a lot simpler. The biggest benefits come from maintaining good hygiene. You're a lot less likely to have null reference exceptions or introduce invalid states. Race conditions are harder when most things are immutable by default. You're also less likely to encode things poorly because your type system sucks. You'll think more carefully about how you write loops, ifs and switch statements because the compiler catches and prevents you from doing boneheaded things. It's also has features that prevent you from accidentally adding cyclomatic complexity. For example, lower-level modules are not allowed to refer to higher-level modules. It's also harder to accidentally make functions recursive because it requires a special "rec" keyword. I realize people dismiss hygiene, but this stuff really goes a long way to help manage complexity when it comes to growing and maintaining applications over long periods of time. I'm not going to claim it's great at everything. It's a wonderful back-end and business language, and it's fantastic at modeling business objects and records. However, the tooling isn't there for doing WPF applications. Also, sometimes you come across issues with libraries that work well with C# defaults but not F# defaults. For example, F# properties tend to be read-only by default, so libraries that hydrate objects with data don't work unless you explicitly make those properties writable. Nevertheless, if nothing else was an issue (buy in, training, etc), I'd opt to write the business logic in F# 9 times out of 10 times and save C# for the front-end (tooling).