6 ms·

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

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

yawaramin 5y ago
> 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

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