4 ms·

As someone who has a lot of time for OCaml - I'm honestly not so big on F# anymore. You end up having to use .NET Objects in F# because their modules are so li

As someone who has a lot of time for OCaml - I'm honestly not so big on F# anymore. You end up having to use .NET Objects in F# because their modules are so limited compared to OCamls. And at that point I figure why not just use C# - which is a lot more expressive than it used to be - and have a lot less friction using the .NET ecosystem?

bob1029 5y ago
> And at that point I figure why not just use C# - which is a lot more expressive than it used to be This is what we do. LINQ and switch expressions wherever feasible. We also integrated a special dialect of SQL into our product which gives us a functional way to specify new views of business state.
- LAC-Tech 5y ago
  Big thing I miss from F# is Option and Either types. You can make both in under 100 LOC in C# but then you have to explain to people how they work or write comprehensive docs. Also, it feels more natural to me to use dynamic dispatch instead of pattern matching with C#, but I realise the "C# is pure OO" ship sailed a long time ago
  - pjmlp 5y ago
    While not the same, you can use nullable for that, but you will get some weird look from C# devs.
    - bob1029 5y ago
      I make a really big deal about proper use of null in our C# codebase. Getting this right is not hard, just monotonous. Recent language features make enforcing this significantly easier than in the past. Any time something isn't quite right I can expect to find a green squiggle under the offending code, assuming I have declared all of my types accurately. The only type in our codebase I don't put a ? on would be string. We have very thorough utilization of string.IsNullOrWhiteSpace() throughout, as we prefer the semantics of this for how our application works.
Cybiote 5y ago
I have a fair amount of experience in both F# and Ocaml and don't think the lack of modules harms F#. The trick I had to learn was to think of F# as its own language and not try to write it as Ocaml or Haskell. What I do sometimes miss in F# are existential types. I also wouldn't say objects in F# are less natural. This is only opinion but, I prefer F#'s lighter object syntax and its object expressions are great. Active patterns also provide an expressive option for dispatching on abstract datatypes. The conflicts vs .NET I've found with F# OOP are when implementing comparison operators, or when interacting with frameworks that want public fields. Other than that, there's not much friction. I suppose there is friction when it comes to MS tooling for producing Windows UIs but then, F# also has Fable and Elm inspired UI kits for various platforms. Going AOT route will also meet with some friction. Comparing languages comes down to what problem solving approaches they make difficult by default. In that light, F# is much more properly a "functional" language than C#. The language is designed from the ground up for recursive algebraic data structures, HM type inference, flexible pattern destructuring, null avoidance, exhaustive matching, computation expressions, idioms around composable higher order functions, clean syntax for function types, immutability and sound type guided development. It also has a light python like syntax and like all MLs but perhaps even more so, is pragmatic when it comes to the use of esoteric design concepts. The philosophy is not to be functional and pure for their own sake but about composing language defaults which force certain types of correctness promoting approaches. F# also has units of measure and type providers. They're probably less often used. But just the json, html and xml providers are useful on their own. To be clear, this isn't arguing F# vs C#. Such arguments are extremely boring. It's emphasizing what core design decisions distinguish the two languages.
throw868788 5y ago
As someone who's used both I generally am not as big of a fan of OcAML where it matters - usage in most companies and projects. Sure it has some features that are nice but often they are "nice to have's", whereas the F# has things that IMO are more necessary for day to day development. Basic things like multi-threading last time I checked weren't as ideal (particularly for FP languages where this can shine); and the library ecosystem in F# basically takes in all of .NET reducing the risk of adoption substantially. At least my team will never be stuck inter-operating with some product, and can keep up with latest trends. What's important are minimising the risk of adoption and also allow FP to show its value since that's what will make the adoption successful. I don't want my dev's to be stuck when adopting the new technology for a project because there is a library missing. On the C# side depends on the problem space. If your working in a space where FP can help shave dev time substantially then F# is the better choice IMO. C# is not bad, but F# shines in certain domains in terms of dev time in my experience.
- yawaramin 5y ago
  > Basic things like multi-threading last time I checked weren't as ideal For most line-of-business/CRUD/APIs/etc. multi-threading isn't really a must-have. Otherwise why are so many people doing just fine with Python/Ruby/Node? OCaml has really good concurrency support (check the OP, they serve hundreds of millions of requests/day with extremely low latency–quoting directly from their slide here). > At least my team will never be stuck inter-operating with some product, Valid point, but it highly depends what you're using it for. I would say for like 90% of web-ish use cases the current OCaml ecosystem would work just fine. > and can keep up with latest trends. That's not necessarily a positive. Our job is to deliver business value, not follow the latest fashionable trends.
  - throw868788 5y ago
    >That's not necessarily a positive. Our job is to deliver business value, not follow the latest fashionable trends. Just to clarify latest trends don't mean untried tech, it sometimes means just new features of existing products making it into your ecosystem. Some examples I can think of include an AWS SDK adding an option to to their SDK's for a well used product that suits your project, better well-tested support for a message bus library used by your company, a vendor product mandated by your organisation providing only mainstream language SDK's (Node, Java, .NET), etc. Yes I could make my own SDK's in OcAML (I like the lang btw) but then I'm not "delivering business value" as per your comment. It also increases the risk of project failure using the time budget allocated - in the team's I've seen using FP this would of been a real risk. > "Basic things like multi-threading" In my time I've seen many projects switch from Node/Python APIs to Java/.NET/C++/etc when they become high scale backends just to take advantage of the better performance envelope. Java/.NET usually is chosen if multi-threading is appropriate. Seen this happen a lot and its pretty common. Seen savings up to 200k+ USD a year for just one component where going multi-threaded helped. Its quite common once a business reaches a certain scale to desire multi-threading for a number of business cases. > For most line-of-business/CRUD/APIs/etc. For those standard CRUD API's you mention unfortunately the ability to use Ocaml, F#, or any other functional language often is reduced unless you are doing it already for other value reasons - its hard to justify the value add over say Java, C# or even Node. The app probably isn't doing too much anyway other than calling a database and serialising the result to the client. It's when you add handle data in those API's or data processes, add algorithms to them (e.g. processing engines, etc), handle data pipelines that FP IMO shows its true business value, and those cases often benefit from multi-threading and/or shared immutable state. F# does well at that, has good async support, and most of the FP goodies (strong typing, type inference, etc), and has an acceptable performance (.NET is pretty good these days). In the end my point is I think F# right now IMO is much "less risky" out of the two to adopt for most corps especially if you are doing data transformation, pipelines, and APIs (given ASP.NET Core's speed these days) especially with the broader library support. YMMV of course and this is a general opinionated statement - if those adoption risks don't apply to what you are developing great.

bob1029 5y ago

> And at that point I figure why not just use C# - which is a lot more expressive than it used to be This is what we do. LINQ and switch expressions wherever feasible. We also integrated a special dialect of SQL into our product which gives us a functional way to specify new views of business state.

LAC-Tech 5y ago
Big thing I miss from F# is Option and Either types. You can make both in under 100 LOC in C# but then you have to explain to people how they work or write comprehensive docs. Also, it feels more natural to me to use dynamic dispatch instead of pattern matching with C#, but I realise the "C# is pure OO" ship sailed a long time ago
- pjmlp 5y ago
  While not the same, you can use nullable for that, but you will get some weird look from C# devs.
  - bob1029 5y ago
    I make a really big deal about proper use of null in our C# codebase. Getting this right is not hard, just monotonous. Recent language features make enforcing this significantly easier than in the past. Any time something isn't quite right I can expect to find a green squiggle under the offending code, assuming I have declared all of my types accurately. The only type in our codebase I don't put a ? on would be string. We have very thorough utilization of string.IsNullOrWhiteSpace() throughout, as we prefer the semantics of this for how our application works.

Cybiote 5y ago

I have a fair amount of experience in both F# and Ocaml and don't think the lack of modules harms F#. The trick I had to learn was to think of F# as its own language and not try to write it as Ocaml or Haskell. What I do sometimes miss in F# are existential types. I also wouldn't say objects in F# are less natural. This is only opinion but, I prefer F#'s lighter object syntax and its object expressions are great. Active patterns also provide an expressive option for dispatching on abstract datatypes. The conflicts vs .NET I've found with F# OOP are when implementing comparison operators, or when interacting with frameworks that want public fields. Other than that, there's not much friction. I suppose there is friction when it comes to MS tooling for producing Windows UIs but then, F# also has Fable and Elm inspired UI kits for various platforms. Going AOT route will also meet with some friction. Comparing languages comes down to what problem solving approaches they make difficult by default. In that light, F# is much more properly a "functional" language than C#. The language is designed from the ground up for recursive algebraic data structures, HM type inference, flexible pattern destructuring, null avoidance, exhaustive matching, computation expressions, idioms around composable higher order functions, clean syntax for function types, immutability and sound type guided development. It also has a light python like syntax and like all MLs but perhaps even more so, is pragmatic when it comes to the use of esoteric design concepts. The philosophy is not to be functional and pure for their own sake but about composing language defaults which force certain types of correctness promoting approaches. F# also has units of measure and type providers. They're probably less often used. But just the json, html and xml providers are useful on their own. To be clear, this isn't arguing F# vs C#. Such arguments are extremely boring. It's emphasizing what core design decisions distinguish the two languages.

throw868788 5y ago

As someone who's used both I generally am not as big of a fan of OcAML where it matters - usage in most companies and projects. Sure it has some features that are nice but often they are "nice to have's", whereas the F# has things that IMO are more necessary for day to day development. Basic things like multi-threading last time I checked weren't as ideal (particularly for FP languages where this can shine); and the library ecosystem in F# basically takes in all of .NET reducing the risk of adoption substantially. At least my team will never be stuck inter-operating with some product, and can keep up with latest trends. What's important are minimising the risk of adoption and also allow FP to show its value since that's what will make the adoption successful. I don't want my dev's to be stuck when adopting the new technology for a project because there is a library missing. On the C# side depends on the problem space. If your working in a space where FP can help shave dev time substantially then F# is the better choice IMO. C# is not bad, but F# shines in certain domains in terms of dev time in my experience.

yawaramin 5y ago
> Basic things like multi-threading last time I checked weren't as ideal For most line-of-business/CRUD/APIs/etc. multi-threading isn't really a must-have. Otherwise why are so many people doing just fine with Python/Ruby/Node? OCaml has really good concurrency support (check the OP, they serve hundreds of millions of requests/day with extremely low latency–quoting directly from their slide here). > At least my team will never be stuck inter-operating with some product, Valid point, but it highly depends what you're using it for. I would say for like 90% of web-ish use cases the current OCaml ecosystem would work just fine. > and can keep up with latest trends. That's not necessarily a positive. Our job is to deliver business value, not follow the latest fashionable trends.
- throw868788 5y ago
  >That's not necessarily a positive. Our job is to deliver business value, not follow the latest fashionable trends. Just to clarify latest trends don't mean untried tech, it sometimes means just new features of existing products making it into your ecosystem. Some examples I can think of include an AWS SDK adding an option to to their SDK's for a well used product that suits your project, better well-tested support for a message bus library used by your company, a vendor product mandated by your organisation providing only mainstream language SDK's (Node, Java, .NET), etc. Yes I could make my own SDK's in OcAML (I like the lang btw) but then I'm not "delivering business value" as per your comment. It also increases the risk of project failure using the time budget allocated - in the team's I've seen using FP this would of been a real risk. > "Basic things like multi-threading" In my time I've seen many projects switch from Node/Python APIs to Java/.NET/C++/etc when they become high scale backends just to take advantage of the better performance envelope. Java/.NET usually is chosen if multi-threading is appropriate. Seen this happen a lot and its pretty common. Seen savings up to 200k+ USD a year for just one component where going multi-threaded helped. Its quite common once a business reaches a certain scale to desire multi-threading for a number of business cases. > For most line-of-business/CRUD/APIs/etc. For those standard CRUD API's you mention unfortunately the ability to use Ocaml, F#, or any other functional language often is reduced unless you are doing it already for other value reasons - its hard to justify the value add over say Java, C# or even Node. The app probably isn't doing too much anyway other than calling a database and serialising the result to the client. It's when you add handle data in those API's or data processes, add algorithms to them (e.g. processing engines, etc), handle data pipelines that FP IMO shows its true business value, and those cases often benefit from multi-threading and/or shared immutable state. F# does well at that, has good async support, and most of the FP goodies (strong typing, type inference, etc), and has an acceptable performance (.NET is pretty good these days). In the end my point is I think F# right now IMO is much "less risky" out of the two to adopt for most corps especially if you are doing data transformation, pipelines, and APIs (given ASP.NET Core's speed these days) especially with the broader library support. YMMV of course and this is a general opinionated statement - if those adoption risks don't apply to what you are developing great.