
F# Not just for finance - markfsharp
https://fsharp.tv/gazettes/f-the-most-highly-paid-tech-worldwide-in-2016/
======
gmantom
While I think F# is a great programming language. The article missed some good
uses of it.

Specifically the article missed one of largest F# deployment, in production,
in the world at this point. We use F# at Jet.com and it powers every part of
our core business from our dynamic pricing algorithm to search and analytics.

Over 4 million customers already on jet and over 2200 cores on azure all
running F# code.

~~~
louthy
> Over 4 million customers already on jet and over 2200 cores

That sounds like a lot of cores for such a small data-set. Are you able to
expand a little more on why you need so much computing resource?

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

That amount of compute encompasses QA, Dev environments and any experimental
and R&D work we are doing.

Plus jet.com is trying to compete with Amazon so that means the system has to
be ready for many million more users than there are currently shopping with
us.

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

~~~
partisan
Do tell... what tools/languages/frameworks/architectures do you use?

~~~
louthy
My comment wasn't so much about languages and frameworks (we use both C# and
F#), but pricing complexity. I'm in healthcare software, and the complexity of
pricing is crazy.

We have a system that joins hospitals, primary and secondary care providers
together. Each hospital might have it's own prices, as will their consultants,
etc. Insurers have standard price lists, but some consultants and practices
have direct deals with them, which can affect the price (and the creditor for
the invoices), we also support rule-sets for modifying prices based on
location, clinician, day of the week, availability, benefit maxima, credits,
etc. We support the notion of inherited prices, where a standard template can
be setup and then used as a basis for more bespoke plans etc. All of which can
be manually overridden. If additional services are added then that can affect
appointment lengths and costs. If the patient self-pays they may get different
prices to what they would on their insurance.

Some of our customers do occupational health where they go out and get
contracts with the big city firms to provide schemes for their employees. Each
deal they get is different and negotiated to the nth degree, which can include
various plans/tarrifs/credits, etc. Some services the patients can book
themselves online, some can only be booked by their HR manager, some as
follow-ups by clinicians, etc. Also rules around what can go on invoices, how
billing items are grouped, who can see what (i.e. should an HR person see what
services you've had etc.)

The additional complexity comes with matching that all up with efficient
scheduling. We have some customers where they have appointments that involve
up to 8 separate clinicians or resources; so they need to be scheduled in and
priced without leaving massive gaps in the schedules. We also support call-
centres that could _see_ 1000s of practices and can query all of them. The end
result looks very much like an airline booking model, but behind it all is a
mass of complexity.

The combinatorial issues are large, and have definitely caused us some
headaches over the years. So I fully understand how these systems can get very
resource hungry. We're not in the same league as Expedia or Jet in terms of
scale (although we hold more patient records than Jet has customers, if that
means anything) - and as I mentioned it's relatively easy for us to silo
groups of users, so I suspect some complexities just go away for us because we
can filter down the potential results quite quickly, but still 2200 _sounded_
like a lot - it was just a gut feeling. I don't understand how a shop selling
a product can have difficulty calculating a price, but just as my customers
have no idea of the complexity involved in calculating prices, I almost
certainly don't understand the complexities that the team at Jet have to deal
with.

The way we've dealt with it is to build massive data-sets of various static
combinations, so if patient X on chargeband Y wants service Z then they'll be
changed N. That does mean some large data updates when someone changes their
pricing and rules; but it means doing less work live - although it can still
be significant. This all runs on two 32 core servers.

~~~
eggy
What languages and platform are you using?

I know healthcare insurance pricing has become the most insane invention of
bureaucracy on the planet. That is why I can pay cash out of pocket and
sometimes get an 85% discount. The providers don't have to chase their money
from the insurance companies - private and government included.

~~~
louthy
> What languages and platform are you using?

C# for the core app, C# and F# for satellite services. Not sure on what you're
asking re: platform. If you mean hosting? Then we roll our own servers in tier
4 data-centres. If you mean OS/framework: Windows Server/.NET

~~~
eggy
Thanks for the information. Any mobile dev with F#, or is it all desk-based?

~~~
louthy
All our mobile stuff is thin web-layers that consume our core APIs, so it's
all js. I started looking at WebSharper and FunScript for a more strongly-
typed and robust web-development experience, but they're all a bit too
'awkward'.

I keep meaning to look into Elm as it appears to be a more thoughtful approach
to functional programming on the client.

~~~
eggy
I avoid JS, not because I don't like it, but there are other choices. Then
again, it's much easier to find JS devs than Elm devs.

I've played with Elm, but not made anything of note with it yet. The
Elixir/Phoenix crowd are getting hopped up about it lately as a good fit for
them.

------
insulanian
There is an interesting article about rewriting C# project in F#, with
impressive results: [http://simontylercousins.net/does-the-language-you-use-
make-...](http://simontylercousins.net/does-the-language-you-use-make-a-
difference-revisited/)

~~~
wrsh07
This is a really great case study, but I can't help but think some of the
improvement comes from it being the second attempt at the project.

I'd really like to see some case studies going the other way: F# --> C# [or
C++].

At the least, you could do C# --> C# [ie complete rewrite]. Any time you do a
rewrite with more knowledge of what worked and what didn't, you'll have a
better system.

So ultimately, the essay [like most] leaves the question: Is F# better? Or is
it just that complete rewrites can provide substantial improvement?

~~~
smoothdeveloper
From all I gathered about people that story was related to, it seems the F#
project was done without looking at the C# implementation, on basis of same
specifications.

If you were tasked to implement a project because first implementation failed,
would you even read the first implementation or just base your work on the
specification?

~~~
wrsh07
Oh good point -- it does say they were separate teams.

Should one read previous implementation? That's a difficult question. If
you're worried about losing your perspective from seeing a single solution,
then perhaps you're right that you shouldn't.

But it's possible that merely implementing it in a different [more functional]
language would encourage sufficiently different patterns to allow you to keep
perspective.

With all of this said, I am a huge fan of both C++ and Haskell. I had just had
an internal realization that these stories might not be extracting the
positive effect that a rewrite might have on a code base [even though, as you
say, that is likely not relevant here].

------
hvs
I was an early adopter of F# (1.0) and promoted it pretty heavily in my
previous job. We used it for some of our prediction code.

I've since left and move to the Linux world, but have become more involved
with using OCaml. Both are great languages (probably my favorites) and that's
after investigating Haskell for a while. F#/OCaml's ability to easily move
between functional/procedural/OO worlds makes it super flexible.

~~~
gnuvince
> F#/OCaml's ability to easily move between functional/procedural/OO worlds
> makes it super flexible.

When I wrote the reference compiler for an intro to compiler class in OCaml,
some of the teams who used Haskell asked me about my choice; I said that while
most of the compiler was written in a nice FP style, it was nice to have
imperative constructs in a few places to follow the techniques from a textbook
without having to adapt them and making sure that I haven't changed the
complexity.

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

~~~
ZenoArrow
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...).

~~~
zem
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](https://github.com/martindemello/fsharp-quickstart)

~~~
SpaceCadetJones
Last I tried there were a couple of issues with autoindentation with the
fsharp plugin for emacs, but they're well aware of the issue and have been
working on it last I checked.

------
Keats
Is anyone using F# on Linux? How's the experience?

~~~
insulanian
I'm running it in prod since last year and from the runtime perspective there
are no issues.

Tooling is what sucks. MonoDevelop F# support is very unreliable. Basic
refactoring, like rename, don't work correctly every time and I had to
literally do git reset few times, after renaming, as it screw up multiple
files.

Also, editor often has visual glitches where letters get corrupted and I have
to reopen the file to get it back to normal. Not something I expect from such
a long time maintained application. However, it looks like Xamarin Studio 6.0
will be much better.

Alternative is Visual Studio Code with Ionide plugin, but I didn't use that
beyond trying it once. Hopefully someone else can comment.

 _Edit: typos_

~~~
7sharp9
Xamarin Studio and MonoDevelop are the same, what your probably seeing are the
artefacts or using an old version of MonoDevelop

~~~
insulanian
I'm using the latest stable release of MonoDevelop (5.10)

~~~
sremani
The latest if you pull from github is 6.1 (I think), using apt-get does not
install the latest monodevelop.

~~~
insulanian
Release notes [1] say: _This is a preview of the upcoming Xamarin Studio 6.1
release._

Is it already released?

[1]
[https://developer.xamarin.com/releases/studio/xamarin.studio...](https://developer.xamarin.com/releases/studio/xamarin.studio_6.1/xamarin.studio_6.1/)

~~~
sremani
Yes, its already out. I had couple of hiccups while installing but was able to
install it from Github.

------
markfsharp
Here is the Louvre Architect demonstrating the use of F# to help with the
design of the structure: [https://channel9.msdn.com/Events/FSharp-
Events/fsharpConf-20...](https://channel9.msdn.com/Events/FSharp-
Events/fsharpConf-2016/The-3D-Geometry-of-Louvre-Abu-Dhabi)

------
ProfChronos
Just tried F# on
[https://www.codingame.com/games/puzzles](https://www.codingame.com/games/puzzles)
Don't really see the use case for me, but fun to try smthg new => "one new
language a day keeps the boredom away"

~~~
NovelSpinGames
That's an awesome website! I made it through the first three puzzles using F#.
It's too bad that there's nothing like IntelliSense there, but you can use
Visual Studio or www.tryfsharp.org for typing and CodinGame for testing. It
looks neat, but might not be the best for learning a new language. You can see
some clever solutions after solving a puzzle at least. How familiar are you
with F# and functional programming?

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

------
melling
I 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...](http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-
retrospective/)

OCaml and F# are quite close.

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

~~~
Drup
You should read the first two blog posts in detail. He didn't knew OCaml at
all at the time, and answers your remark about Go directly in the second post.

~~~
vessenes
I did read those. I think it comes down to speed on boot, which seems like a
legit concern, and a matter of taste. To wit:

Should os.Getenv return an empty string or an error if the environment
variable is not set? -- The answer to this depends on how unix-y you are, I
suspect. We might disagree, but it's not wrong to say that you're going to do
what bash does, which is, after all the fundamental place these are kept, and
return an empty string. In particular, this is well documented in the API,
regardless.

If I create an empty list, then marshal some uninspected text into it, and
that marshal function fails but I don't check its error status, should my list
be poisoned, or should it continue on as empty? -- The idiomatic answer to
this is that you should check error status and remediate.

He would prefer that the program vomit when marshaling fails. Fine, but it was
entirely his choice to code in this style, against go style guides. To then
claim the compiler is 'unhelpful' later when he tries to read the list he
declared is empty is blame shifting in my opinion.

I would guess he does not prefer in-line error checking and remediation as a
pattern; that's totally fine, but it's annoying to read snark about it.

~~~
Drup
If you read more carefully, you would see he would prefer that the language
would not allow him to ignore errors.

You say "The idiomatic answer to this is that you should check error status",
yes, that's a Go design pattern, but nothing enforces that. In other
languages, thanks to Option/Result types, this is enforced, hence his opinion.

Such kind of safety and security concerns should not be enforced by
conventions.

------
dintech
I'm quite sure KDB pays more.

------
pmarreck
I want to suggest looking at a language like Erlang/Elixir that didn't start
out from corporate self-interest (i.e., was open-source from the get-go) but a
rising functional tide floats all boats. (And besides, Elixir "borrowed" a few
good ideas from F#.)

I've had nothing but good experiences during my forays into functional langs.
Here's to a more functional, immutable, easily-concurrent, easily-unit-tested
future

~~~
eggy
As commented by others, F# was part of Microsoft Research, and not taken up by
MS or other corporations when it was started.

Erlang started out in Ericsson, a corporation. Elixir and LFE (Lisp Flavored
Erlang) started out opensource and are still opensource.

The term 'corporate self-interest' seems misplaced here, with the
parenthetical remark turning it into the antonym of 'open-source'. The term
proprietary, commercial or close-sourced seem more neutral and correct.

Erlang started inhouse at Ericsson, like F# did at MS Research, except it was
for a company's immediate business needs or 'self-interest' to program their
telecomm switches.

Elixir grew out of one person's frustration with Ruby's concurrency (Jose
Valim), and a desire to have what Erlang offered him along with the BEAM VM
and OTP. It has Ruby-like syntax, Jose is a popular Rubyist, and great tooling
along with some other functional structures Jose added that he thought were
missing in Erlang. [2]

Pony is an OO, actor-based, open source language, yet it has a lot of
corporate pickup from fintech and others, and it seems to be getting ready to
shove Erlang/Elixir/LFE aside on concurrency and speed. It has fully-
concurrent garbage collection that doesn't use the "poison pill" message
approach to kill all actors.

The creator of Pony, Sylvan Clebsch, has one foot in academia, and the other
in business. He has worked on fintech, milsims, and games. [3]

[1] [http://www.ponylang.org/](http://www.ponylang.org/)

[2] [https://www.sitepoint.com/an-interview-with-elixir-
creator-j...](https://www.sitepoint.com/an-interview-with-elixir-creator-jose-
valim/)

[3] [http://www.curry-on.org/2015/sessions/pony-making-it-
easier-...](http://www.curry-on.org/2015/sessions/pony-making-it-easier-to-
write-efficient-concurrent-programs.html)

~~~
pmarreck
I agree with everything here except for the Pony promotion because after
working on OO codebases for 15 years now, I am mostly convinced that OO has
fundamental design flaws, at least when it comes to the long-term scalability
and maintainability of codebases.

Unfortunately it is difficult to "prove" this definitively currently, until
someone comes up with a "complexity polynomial metric over time" for code,
except to talk to old programmers like myself (44) who have done this for a
long while and gotten disillusioned due to all the time spent repairing OO
complexity/tech debt bugs, and have become entranced by functional langs and
the way they avoid inheritance, use immutable values and are super careful
with state, all of which contributes to better long term code life

Fortunately I'm not the only old OO guy proclaiming this, I have John Carmack
on my side:

[http://www.gamasutra.com/view/news/169296/Indepth_Functional...](http://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php)

"My pragmatic summary: A large fraction of the flaws in software development
are due to programmers not fully understanding all the possible states their
code may execute in. In a multithreaded environment, the lack of understanding
and the resulting problems are greatly amplified, almost to the point of panic
if you are paying attention. Programming in a functional style makes the state
presented to your code explicit, which makes it much easier to reason about,
and, in a completely pure system, makes thread race conditions impossible."

"No matter what language you work in, programming in a functional style
provides benefits. You should do it whenever it is convenient, and you should
think hard about the decision when it isn't convenient."

~~~
eggy
I heartily agree with what you have said. It is the reason I am not really
biting at Pony. Maybe if I needed everything else it offered, or fully
understood everything else it offered?

The problem I see now is that the entire functional domain is so spread out -
Clojure, F#, OCaml, Haskell, Idris, Erlang/Elixir/LFE, and even the APL/J/K/Q
crowd and Java's attempt to go functional. I'm not complaining about the
number of functional languages to choose from, which is good. It's whether
there will be enough critical mass in any one of the functional languages
given a new non-functional language popping up every week. I don't know.

Now that MS has opensourced so much, and Xamarin's stuff is free, F# is
looking better to me (again).

I also find myself dropping to C. C was my third language (after 6502 assembly
and CPM Basic). Haskell/Idris/Elm are my toys of the year. I never fully dove
into Haskell, but the concise, readable and very mathematical syntax agrees
with my sensibilities.

Old! I'm 52, but I didn't stay with programming for a living, so my age
doesn't reflect my programming experience. I did start with a CPM PET in
1978/79, but then went on years later to do other things.

------
gtycomb
Is porting OCaml code to F# on Unix straight forward? Is there something
similar to the Opam package manager in F#? Thanks for your thoughts.

~~~
strmpnk
F# is similar but if you're using features like polymorphic variants,
functors, or first class modules, it might take more effort. In terms of
package management, I'd check out paket. It wraps up the otherwise very quirky
nuget system that .Net uses and also supports things like source dependencies.

------
haddr
Where is R on those charts on functional languages?

------
mamcx
Where are the best place to find that F# jobs? I will love to work on it (+17
developing but this years I have picked F#)

~~~
smoothdeveloper
UK seems to have the most adoption of F#.

------
manish_gill
This was a bit of a surprise to me. Is there a disproportionate amount of
people in Finance using F# compared to other technologies? Any particular
reason for that if the answer is yes?

------
bwooceli
A high price tag for a niche language (purely defined by "popularity") is
hardly surprising, simple question of supply and demand.

------
bad_user
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 likely reversed - good developers
that tend to be well paid are also the kind of people naturally interested in
expanding their skill set, hence interested in FP languages.

Nothing screams spam more than usage of a hot keyword like " _functional
programming_ " while leaving hints that you don't understand what you're
talking about. I would expect an article that reads like a marketing brochure
to at least make a short attempt at explaining what functional programming is.
If you copy/paste testimonials from fsharp.org/testimonials, you could also
copy/paste from Wikipedia. But then, their own course named "Functional
Programming" doesn't seem to have anything to do with actual functional
programming: [https://fsharp.tv/courses/functional-
programming/](https://fsharp.tv/courses/functional-programming/)

~~~
jackmott
F# was also voted most LOVED language in the F# survey.

~~~
smoothdeveloper
In the Stack Overflow survey :)

------
mjfl
any good tutorials for F#?

~~~
jackfoxy
While I agree
[http://fsharpforfunandprofit.com/](http://fsharpforfunandprofit.com/) is the
best all around resource, for just a tutorial I recommend
[https://en.wikibooks.org/wiki/F_Sharp_Programming](https://en.wikibooks.org/wiki/F_Sharp_Programming)

Also be sure to check out the F# Foundation site
[http://fsharp.org](http://fsharp.org)

------
spazzpp2
Long time no see, #F.

------
hackaflocka
> F# came out as the single most highly paid tech worldwide and is amongst the
> third top paying techs in the US

Wouldn't the latter be implied by the former? Or am I missing something?

~~~
jboynyc
That is confusing/questionable wording, but it can still be logically
consistent. Here's an analogy: Football (soccer) is the most popular sport
worldwide, but it is not among the top sports in the U.S.

------
mariusmg
Programming languages are hyped now worse than cars : "From code to colossal:
Waagner-Biro recently used F# to construct the dome of the Louvre Abu Dhabi
museum" They used X programming language to build the dome of a museum ?
Wowwww...

It's sad.

~~~
nickpeterson
Construct is probably a poor choice of words. Design would be more accurate.

