5 ms·

> 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. Sure, fair–OCaml is not all th

> 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. 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.

throw868788 5y ago
I like OcAML as well - in fact I stated that. The original reply was to a comment comparing OcAML to F# in the context of adoption in a company to a risk adverse poster worried about costing the company "mega dollars", where one reply dismissed F# due to .NET interop. My point was really that's also the reason why IMO it is less risky to adopt for many corporations for a person such as this - there's less chance to be blocked by some missing thing. Awkward but workable on the edge cases beats having to do more work for many projects in the real world we live in. 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.
- yawaramin 5y ago
  If we are talking about adoption and name recognition among non-engineers (despite this being a very poor way to run software engineering projects), then unless you are already a .Net shop I see no compelling reason to adopt it over JVM and (if typed FP is desired) Scala. Everyone knows Java, and Scala probably has at least twice the adoption levels of F# (pulling numbers out of thin air here).
  - throw868788 5y ago
    I think there are factors to consider one over the other; just like sometimes OcAML could be a good choice as well. I wouldn't dismiss F# for production use however having seen it used successfully on large things in Windows and Linux environments. > 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.

throw868788 5y ago

I like OcAML as well - in fact I stated that. The original reply was to a comment comparing OcAML to F# in the context of adoption in a company to a risk adverse poster worried about costing the company "mega dollars", where one reply dismissed F# due to .NET interop. My point was really that's also the reason why IMO it is less risky to adopt for many corporations for a person such as this - there's less chance to be blocked by some missing thing. Awkward but workable on the edge cases beats having to do more work for many projects in the real world we live in. 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.

yawaramin 5y ago
If we are talking about adoption and name recognition among non-engineers (despite this being a very poor way to run software engineering projects), then unless you are already a .Net shop I see no compelling reason to adopt it over JVM and (if typed FP is desired) Scala. Everyone knows Java, and Scala probably has at least twice the adoption levels of F# (pulling numbers out of thin air here).
- throw868788 5y ago
  I think there are factors to consider one over the other; just like sometimes OcAML could be a good choice as well. I wouldn't dismiss F# for production use however having seen it used successfully on large things in Windows and Linux environments. > 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.