I came across F# a couple of months ago. Very nice language! Short, expressive, no noise like declaring vars/types that can be easily inferred at compile time. |> is amazing. Tuples. 'match with'. Took a couple of weeks to get over the hump, but I never looked back since. Work related stuff is still C#, but tooling, prototyping etc I do in F# now. Highly recommend. Also made me to rediscover glorious past of OCaml/ML that went over my head at the time (like most things).
F# Not just for finance
51–60 of 138 posts
Re: F# Not just for finance
#52Is anyone using F# on Linux? How's the experience?
It works, although from what I recall the installation wasn't that easy. I think I had to checkout a specific tagged commit instead of the newest master, because the latter had a broken build. Probably works now, it was years ago :)
This is all I need usually:
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
echo "deb http://download.mono-project.com/repo/debian wheezy main" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list
sudo apt-get install -y mono-complete fsharp monodevelopRe: F# Not just for finance
#53Earlier quoted context omitted.
Small note about Nuget, you might consider upgrading to paket (works nice with C# too): http://fsprojects.github.io/Paket/ It removes so much pain compared to raw usage of Nuget and is very easy to learn/adopt.
> It removes so much pain compared to raw usage of Nuget and is very easy to learn/adopt We have a very large number of projects and migrating them all to paket would be a hassle, so I'd be interested in what pain in particular it removes? I'm no fan of nuget I can tell you, but I'd be interested to understand what you feel the big wins are
* reduced churn on proj files
ensure consistency of dependencies across repository (can't do that with so many packages.config files)
* easy to figure out outdated dependencies / update those with changes that are very easy to diff
* no need to battle with transitive dependencies
* several transitive dependencies resolution algorithm (max can be used to be as up-to-date as possible)
* ease support for multi platform targeting (it puts conditionals around the references, when you switch platform, it switches to correct assemblies without you having to do anything)
* will write/maintain binding redirects related to nuget packages for you (saves from many runtime errors)
* can generate include scripts for nuget packages if you do .csx or .fsx scripting
* many more things
the UI integration in VS is not as good but if you look at it, the UI is also part of the problem with Nuget (doesn't work on several solutions, doesn't really understand transitive dependencies, etc.).
You can migrate with single command line, and start improving from then on.
Re: F# Not just for finance
#54Earlier quoted context omitted.
F# has fantastic concurrency support. Great support for Asynchronous operations and Multi Threading. Being a functional first language and immutable by default means most of the micro services are stateless and this means we can take advantage of concurrency like crazy and not worry too much about race conditions. I think functional languages in general make concurrency much easier not just F#. GC on the other hand i…
I should have been more specific in the question. I'm used to Erlang and Haskell (GHC) concurrency primitives and frameworks. To reformulate: what concurrency models can you employ in F# that don't involve manually managing threads/processes?
I'm an engineer at Jet and hopefully I'll be able to answer your question. The concurrency model within F# is based on continuations. The type Async = (('a -> unit) -> unit) - its a function which accepts a callback to be notified when the async operation completes. The existing .NET ThreadPool is used to schedule these continuations across OS threads. It uses a trampoline to tame the stack. The ThreadPool itself is a fairly sophisticated piece of work, with scaling heuristics, work-stealing queues, etc. The ThreadPool interacts with the Windows IO completion port multiplexer for IO. We extend this primitive in a variety of ways, notably into an AsyncSeq which in Haskell terms is ListT Async - a linked list interleaved with Async. We use this for stream processing, sockets, fault tolerance, etc. Async is very similar to Haskell's IO monad, although the representations are a bit different.
However, both Async and IO are insufficient to represent disjunctions. To that end, another concurrency library that we use is Hopac. Hopac is an F# implementation of CML, with some differences. Hopac provides a notion of an alternative (called event in CML; think Haskel's Alternative typeclass if you relax the laws a bit) and synchronous channels (note that async channels are special cases of sync channels). Hopac's has experimental support for lawful MonadPlus as well (see transactional events in Haskell = IO + STM + CML).
Some things that we're heading towards next are generalizing STM to be a bit to be more like RCU (see relativistic Haskell). Additionally, we are experimenting with extending this to session types, but nothing in production yet.
F# also provides a MailboxProcessor, which is similar to an Erlang actor, however without explicit distribution support, so perhaps more of an "agent". We typically use this as a low-level concurrency primitive, rather than a full-blown programming model. Most of our services are compositions of various request/reply interactions, and the Async model above is a great fit for this. In fact, we've primitives centered around the notion of an arrow 'a -> Async (specialized to Async). These primitives provide support for fault tolerance, logging, tracing, etc.
All of this works well with the GC. Async does cause allocations of course, but this is a price we're more than willing to pay. We've shared some GC dumps with the designer of the .NET GC and she believes they are sensible for a functional language. Hopac took optimization to a greater extreme, reducing allocations where possible.
Another F# library of interest is MBrace. This takes the notion of Async and fits it with a scheduler that schedules across a cluster rather than an individual instance.
Hopefully this helps!
Re: F# Not just for finance
#55I enjoyed reading this retrospective about someone converting 30,000 lines of Python to OCaml. http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret... OCaml and F# are quite close.
I only know Go well enough to comment on his comments, but he did not do a good job testing and reporting on it in his posts, ignoring basic recommendations about safety taught to all beginners. (Ignores err responses from functions and then later complains that things fail later, most particularly).
I would be cautious about drawing too many conclusions about languages he didn't end up picking; clearly he knows OCaml and Python well.
Re: F# Not just for finance
#56Earlier quoted context omitted.
> It removes so much pain compared to raw usage of Nuget and is very easy to learn/adopt We have a very large number of projects and migrating them all to paket would be a hassle, so I'd be interested in what pain in particular it removes? I'm no fan of nuget I can tell you, but I'd be interested to understand what you feel the big wins are
We have an almost identical setup to yours. How do you manage the long build chains in team city with the number of nuget packages you have? It's something we are grappling with and are considering moving everything back into a single repo with no nuget packages as a result.
Our eco-system is wide rather than tall. We have a solution that is a general purpose set of libraries that most of our projects include, then our core app which is a 50+ project solution, and many satellite service solutions.
The satellite services communicate with each other through my LanguageExt.Process system which is a clustered actor-library, and so as long as the message formats stay the same they can be built and updated separately.
Each solution has a '.Dependencies' csproj included that contains all of the nu-get dependencies. It builds to ../bin, and then all of the projects in the solution add their dependencies from there. That means it's relatively easy to manage the dependencies for each solution.
There's a manual element of waiting for a project to build [on TeamCity] before updating the references in projects that depend on it, but on the whole it's not been too bad.
Re: F# Not just for finance
#57Earlier quoted context omitted.
F# has fantastic concurrency support. Great support for Asynchronous operations and Multi Threading. Being a functional first language and immutable by default means most of the micro services are stateless and this means we can take advantage of concurrency like crazy and not worry too much about race conditions. I think functional languages in general make concurrency much easier not just F#. GC on the other hand i…
I should have been more specific in the question. I'm used to Erlang and Haskell (GHC) concurrency primitives and frameworks. To reformulate: what concurrency models can you employ in F# that don't involve manually managing threads/processes?
I work with F# and have a lot of experience with Erlang (less so with GHC and it's lightweight green threading but I've heard good things about it).
F# inherits lots of .Net's primitives which at their core are thread pool based task scheduling with the usual optimized data structures you see from this world. While this might sound primitive, F# takes it further by providing very good functional libraries which abstract this away allowing lightweight asynchronous computations to be passed around as values (the type being Async).
Alone, this is pretty nice but it wouldn't feel as natural without computation expressions which are similar to Haskell's do-notation but with some generalizations and flexibility added in. This allows asynchronous code to look and feel first class. If you're curious I'd check out https://fsharpforfunandprofit.com/posts/concurrency-async-an... or check similar links on your search engine of choice.
Now, the story isn't complete. If you're comparing things to Erlang, there are also things like MailboxProcessor and such which allow other common patterns to be easily implemented. The type checking here is a nice bonus over some other approaches to message passing languages. The big minus of course is that it's still a traditional runtime. If you really want Erlang's isolated processes, it's hard to do that well outside of a runtime like BEAM. I also think F# could use better fault-tolerance primitives but I'm actively working on this with heavy influence from my work with Erlang.
Re: F# Not just for finance
#58Earlier quoted context omitted.
We use it for satellite projects around our core C# app (the only reason the core isn't F# is legacy, so I created a C# library to get as close as possible when updating/refactoring [1]). The toolset is pretty boring/standard though: VS2015 + TeamCity + in-house Nuget + Gitlab [1] https://github.com/louthy/language-ext/
Hey Louthy. Just wanted to say that I really appreciated your framework.
Thank you :) Out of interest, what are you using it for?
Re: F# Not just for finance
#59Earlier quoted context omitted.
I should have been more specific in the question. I'm used to Erlang and Haskell (GHC) concurrency primitives and frameworks. To reformulate: what concurrency models can you employ in F# that don't involve manually managing threads/processes?
I'm an engineer at Jet and hopefully I'll be able to answer your question. The concurrency model within F# is based on continuations. The type Async = (('a -> unit) -> unit) - its a function which accepts a callback to be notified when the async operation completes. The existing .NET ThreadPool is used to schedule these continuations across OS threads. It uses a trampoline to tame the stack. The ThreadPool itself is…
Thank you, that satisfies my curiosity.
Re: F# Not just for finance
#60Earlier quoted context omitted.
Have you ever used Jet? Try it, add a few things to your cart then add a few more and see what happens to the prices of the previous items. There are millions of permutations being computed behind the scenes. The system is computing prices all of the time based on many factors. Plus we have built everything in house from our warehouse management system and supply chain tools to order management and everything else. T…
I haven't used Jet, no. I'm not trying to call you out, just wondered why it was so large. I have to deal with a similar amount of pricing complexity (actually, probably more complex than Jet) in my line of work, and we don't need anywhere near that amount of resource, but granted we don't have your numbers either, and our setup is much easier to silo groups of users - so probably not directly comparable.
Do tell... what tools/languages/frameworks/architectures do you use?