Live data from Hacker News

F# Not just for finance

fsharp.tv

61–70 of 138 posts

Re: F# Not just for finance

#63

I think the article is spammy and has a clickbait title. Unfortunately reading and addressing the actual article on Hacker News is old-fashioned. StackOverflow surveys, while interesting, are probably meaningless because they suffer from selection bias. Even so, I would guess that F# developers are very well paid, like other developers of FP languages, but it's probably not because they work with F#. The causality is…

> their own course named "Functional Programming" doesn't seem to have anything to do with actual functional programming

Why do you think so?

Re: F# Not just for finance

#64
post #35

Earlier 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…

Also, to compare with other languages:

Async is similar to a Future (such as in Java), with the difference that Future produces a result once and caches it, whereas Async re-evaluates each time it is executed. It can be made to cache of course. A Future is more like a TPL Task, though IMO, Async provides a more predictable programming model.

Go has go-routines and channels. A go-routine is similar to Async. In essence, they are a notion of light-weigh thread. Note however that Hopac support for channels is far richer than that of Go.

Re: F# Not just for finance

#65
post #2

I liked tinkering with F# on VS Code with Ionide ( https://marketplace.visualstudio.com/items?itemName=Ionide.I... ), but would love to hear from folk doing F#/OCaml as to their toolsets.

As far as I'm aware, the most popular F# tools for writing code are (from most to least popular): Visual Studio, Ionide (either using Atom or VS Code) and Emacs. I haven't seen that many people coding in F# using anything else, but I'm sure you'd find a few people using the usual suspects (Vim, Sublime Text, etc...).

I use vim, but the lack of autoindent support is a bit of a pain. I've been meaning to check out spacemacs and see if it does any better there.

also I'm just learning f# and I've started a small project to capture the paket and forge commands needed to get up and running: https://github.com/martindemello/fsharp-quickstart

Re: F# Not just for finance

#66
post #35
post #21

Earlier 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?

For actor model: http://getakka.net/ https://msdn.microsoft.com/visualfsharpdocs/conceptual/contr... For channel/~process calculus: https://github.com/Hopac/Hopac/blob/master/Docs/Programming.... https://github.com/fsprojects/FSharp.Control.Reactive

There is also the Async monad: https://msdn.microsoft.com/en-us/visualfsharpdocs/conceptual...

Ofcourse it is also possible to use standard .net stuff like the TPL https://msdn.microsoft.com/en-us/library/dd537609(v=vs.110)....

Re: F# Not just for finance

#67

Earlier quoted context omitted.

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 monodevelop

The equivalent snippet for Fedora would be most welcome, too ;-)

Re: F# Not just for finance

#68

I think the article is spammy and has a clickbait title. Unfortunately reading and addressing the actual article on Hacker News is old-fashioned. StackOverflow surveys, while interesting, are probably meaningless because they suffer from selection bias. Even so, I would guess that F# developers are very well paid, like other developers of FP languages, but it's probably not because they work with F#. The causality is…

I think the title can be alleged mostly to the misconception which is prevalent at Microsoft since F# was introduced as a commercial product (before it used to be a Microsoft Research product).

Maybe you are unaware of that?

F# is a pretty good general purpose programming language and that is what the title and article tries to promote (albeit it doesn't give enough and diversified examples).

F# is also a reasonably easy programming language which puts emphasis first on "functional programming" (which you frame as hot keyword, I doubt the language was made to fill a hot keyword).

I don't know about the for pay contents of fsharp.tv, but I gather they might be introductory and try to bring understanding of "functional programming" aspects to an audience which isn't versed in it, it is sure good for them if "functional programming" is a hot keyword and people are looking for training material to pickup that language, but I wouldn't dismiss that as being spammy.

Chill out dude :)

Re: F# Not just for finance

#69
post #13
post #9

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

I used jet.com and I got my box from Amazon :)

Re: F# Not just for finance

#70
post #56
post #32

Earlier quoted context omitted.

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 buil…

it is 'paket.references' file next to each proj file and a single 'paket.dependencies' at the root of the repository.

You can also integrate the restore part to msbuild so it works out of box from visual studio, msbuild, teamcity, whatever.

People prefer though to have separate restore packages step, the same way people prefer to use a better tool than raw msbuild to orchestrate build tasks (tool such as FAKE http://fsharp.github.io/FAKE/).

Post reply on HN