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?
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.
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.
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.
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.
Sure, fair–OCaml is not all things to all people. Use as and if appropriate, after having researched the requirements and the available libraries. E.g. see OP–Bloomberg–who found appropriate use cases.
> It also increases the risk of project failure using the time budget allocated
If a software project is being developed on a 'time budget' I have my doubts that it's being run the right way. Software project estimates are mostly useless in my experience, and they usually end up taking however long they take, after stressing everyone out needlessly with meetings and email about why it's taking so long.
> in the team's I've seen using FP this would of been a real risk.
Or it may have ultimately been a better choice, because of correctness and maintainability benefits which kick in after the project has ramped up. I've mentioned this elsewhere in the thread as well. It's hard to make a decisive argument like this based on only a few points of experience. For every experience you have, someone else may have the opposite experience.
> Its quite common once a business reaches a certain scale to desire multi-threading for a number of business cases.
Then why were they written in Node/Python in the first place? Because they were cheaper and faster to develop than they would have been as Java/.NET/C++ projects, and allowed the project to actually survive so that it could face the challenges of scaling up. What you are talking about here is basically survivorship bias.
IMHO, what OCaml offers is a middle ground, a development pace slightly slower than Node/Python, but much faster and safer than the heavy-duty typed OOP languages, and with performance benefits that may mean that you never need to worry about migrating to something else for scalability. Again, see OP.
> its hard to justify the value add over say Java, C# or even Node.
It's hard to justify the value add if the project is being run by non-engineers/MBAs/etc., it's easy to justify if run by experienced engineers who get the bug-squashing benefits of OCaml's typed FP and iteration speed.
> F#
F# is a great language. Just like OCaml, it has its place in certain areas e.g. in Windows/C# shops that are looking for something better.
F# isn't that risky of a language to adopt and even to non-engineer management types as you say - it's .NET. To most of them, they wouldn't know the difference so in that context it is "less risky" for that poster.
I replied with my opinion that for many enterprises (not all) looking to move into FP, F# would seem a less drastic change with many of the benefits (library interoperability/ecosystem size, threading, etc). That doesn't apply to the use cases in this article which is great/fantastic - I'm all for that!
I actually agree with most of your points, but adoption is just as much about convincing others as it is technical qualities, maybe even more so. Getting people onto the journey and making them comfortable with the risk is important.
I would argue with .NET Core F# more has an equal place on the server side (Linux even) given the problems it is more geared to solving. They are both good languages, one is based on the other after all with slightly different tradeoffs. Both OcAML and F# are more similar than different IMO.
> talking about adoption and name recognition among non-engineers
Agree that non-engineer recognition it is a poor way to run projects but sadly that matters to some engineers I've talked to as well + comfort zones. Having F#/Scala experience means they could always find a C#/Java job and that depends on the city/industry you are in as an example.
> I see no compelling reason to adopt it over JVM
That's an opinion preferring the JVM over the CLR which is a stating potentially a personal preference? Technically both are capable so I think that's a moot point - the CLR is pretty good and Java on some things is playing catchup (e.g. value types). JVM is good too but the differences won't probably mean much to most projects.
> Scala probably has at least twice the adoption levels of F#
Scala has many good points and some use cases better than F# for sure. However to play the other side some reasons I can think of on the F# side include that default web performance favors ASP.NET Core (even on Linux) from bench marking by quite a bit over say Spring Boot/Play. The HM type inference also is a plus for F# IMO (as it is for OcAML) and it leans to being more FP first giving the FP benefits quicker with less fuss. The multi threading (Futures/Async-Await) API seems more ubiquitous in the .NET space last time I checked, less LOC to use, and is exposed on a lot more libraries/clients/etc as a first class citizen. Its also IMO a lot easier to make your whole program async and has more inbuilt language support to avoid overhead. Important things in hosting an API I think especially around thread use/scalability. F# has things like value types, compile time generics, tail recursion (for FP), Spans, and other CLR features etc which allow that low level performance tuning where required - it seems to be closer to the CLR than say Scala is to the JVM. Something I do like, just like C#, is to compile it to self packaged bundles for multiple targets (ARM, MacOS, Windows, etc) in a smaller bundle than JVM based apps.
Popularity is a proxy for risk. I would assert it only matters IF the base isn't mature and it doesn't have an ecosystem to piggy back on. Popularity is a proxy measure for "something's probably missing" which for say Scala/F# isn't really the case given their ecosystems depending on your use case. OcAML is probably less popular than F# as an example but for certain use cases could still work - sadly it doesn't have that ecosystem to piggy back of and that is a factor for some teams (not all but many I've been in). F#'s been around for awhile and reasonably mature as a base.
Scala is a good language too. But I wouldn't dismiss F# in these comparisons either. There's nuances that need to be considered. Where you want a language with the crisp FP first feel/benefits of OcAML with an ecosystem just large enough to avoid risk F# is a good compromise and will work quite well. TL;DR Nothing's perfect, more similarities than differences, and as long as you aren't blocked language isn't the big factor in project success/failure that many make it out to be.
- If we're going to talk about benchmarks games I'd need to see evidence, it's hard to believe .NET can offer anything more performant than say Vert.x or Micronaut :-)
- Scala has type inference (not HM, but then again almost as good)
- Futures/async/await are ubiquitous in Scala, the standard library ships with a very reasonable implementation of Future, and there is no shortage of third-party async libraries/runtimes, even leaving aside Akka which has actually been ported to Akka.NET
- Scala has value types
- No compile-time generics but powerful equivalent capabilities like type classes
- Scala has tail (self-)recusion
- JVM has plenty of low-level performance tricks
- Scala is plenty close to the JVM, I don't know how it is with F# but I know for sure e.g. things like Scala lambdas map exactly 1-1 to JVM lambdas
- Not sure when C# got 'self-packaged bundle' capabilities but if we're talking about that kind of thing, there is GraalVM and you can compile Scala apps to native binaries (as long as they don't use runtime reflection and a couple of other restrictions). E.g. https://cloud.google.com/blog/topics/developers-practitioner...
I was actually rather disappointed after looking at Scala native. From what I gathered you can’t create libraries (shared or static) only direct executables.
> I'd need to see evidence, it's hard to believe .NET can offer anything more performant than say Vert.x or Micronaut :-)
Benchmarking is interesting because it depends on your case, and the tricks used in the benchmark. Techempower has proxy benchmark at https://www.techempower.com/benchmarks/#section=data-r20&hw=... for just the web layer which shows aspcore quite high. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... I note it isn't as good with DB queries (DB framework) than Vert.x which gives points to Scala for db like APIs but there's tricks there too. Benchmark Game seems to have F# compare well with Java and OcAML (low level non-idiomatic code there I'm sure too). Been meaning to try Vert.x.
- Futures/async/await are ubiquitous in Scala
I need to look into this more but using them in the past it seems very library based (map/foreach/for comprehensions/flatMap/etc) whereas the .NET implementations tend to be like co-routines (state machine) that are compile time constructs with associated perf benefits. It adds a lot to performance; you want the async primitive to be as cheap especially if doing them in hot loops - .NET articles are full of Task/Async patterns and their benchmarks and optimizations to Tasks are constantly ongoing.
> - Scala has value types
Not in a way that I use them I guess. https://docs.scala-lang.org/overviews/core/value-classes.htm... shows quite a few limitations. They may be overcome with Project Valhalla? but it isn't there yet - its a JVM limitation not a Scala one.
They seem to be extremely limiting compared to .NET types where you can compose things together (more than one value, etc). I use this for math ALL the time avoiding any GC events at all - there's a lot of cases for quick stack allocated values that can cross function boundaries. I've worked on the JVM - its possible but much harder with uglier code. .NET seems to have many more ways to avoid "boxing" than the JVM when the JIT doesn't catch it. Especially with generic methods (unless inlined). Basic tuples, ValueTasks (like futures) and such all use this construct at times.
- JVM has plenty low level performance tricks
Sure it does. I'm liking the new things in .NET Core like Span making it "safe" to do them vs Unsafe and interop. Re-using memory (slicing parts of strings without cloning chars), etc in a safe manner is a simple example but there are others.
> Scala is plenty close to the JVM
Plenty of its abstractions however however require allocations and objects (e.g. implicits everywhere) - futures being one. IMO maybe its just me but it is easier to reason about F# performance. An example in F# would be that many allocations are only allowed explicitly (e.g. math conversions) - it actively discourages implicit behaviour for simplicity I feel. e.g. Auto-Boxing in erased generics has caused perf problems in some JVM programs I used to work on. Both platforms are capable and have their own pitfalls of course.
- self-packaged bundle' capabilities
.NET Core feature.
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.
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
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.