Comment by nextos | Hacker News Reader

Comment by nextos | Hacker News Reader

Parent Full thread

I see a decent number of openings in the City of London quite regularly for finance and insurance positions. Also OCaml and sometimes Haskell. Even Rust has started popping up recently.

I find this a bit intriguing because the library support for linear algebra, probability and statistics is pretty slim both in .NET and OCaml. The latter has OWL, which is very cool, but it's mostly a 1-person project.

Do they develop all this support in house? For example, in insurance you may need things like Gumbel or Fréchet maximum likelihood estimators. That's not so easy to implement on your own, especially not without some linear algebra and optimization primitives available.

On the other hand, I love these languages, and I wish there was a strongly typed contender to Python, R or Julia. Whenever I develop a data-oriented application, it feels like I need to prototype in one language and in order to scale or develop the whole infrastructure, I need to switch to another language.

Julia has solved some of these problems, but I don't see a team implementing tons of business logic in a medium sized application using Julia.

Usually on the .NET ecosystem such stuff just gets bought.

https://www.quantconnect.com/blog/top-numerical-libraries-fo...

F# is your strongly typed contender to Python.

Sure, it's a lovely language. But I find the lack of some basic linear algebra, probability and statistics libraries frustrating. As pjmlp said in a parent thread, those are closed source and usually bought.

I guess a lot of the .NET ecosystem is like that. It's a shame, because MS has some open-source jewels like Z3 or Infer.NET.

MS is making a conscious effort to push into the ML space with libraries such as ML.NET https://dotnet.microsoft.com/apps/machinelearning-ai/ml-dotn... . IMO, the combination of a strongly-typed language with features such as type inference, data providers and discriminated unions/pattern matching make F# a perfect fit for this space. It's just unfortunate that they had to go through the .NET Framework -> .NET Core journey before focusing on the ML ecosystem...

But, the F# PM has recently given talks recognizing that they want to go into the space that Python is dominating, so it's a clear goal of the F# team (https://www.youtube.com/watch?v=_QnbV6CAWXc). I hope they're successful!

On the other hand, they just hired Guido, have first class support for Python across VS and VSCode, and are in the process of creating a Python projection for UWP (which still doesn't support F#).

From the outside it always looks like an uphill battle for F#.

It would be great if F# finally gets its place across the .NET stack.

Odd. I've been using F# for a UWP app since 2018.

Odd indeed, given that .NET Native doesn't support it without a couple of hacks.

https://github.com/dotnet/corert/issues/5780

https://github.com/dotnet/fsharp/issues/1096

As per those links - the workarounds found in 2018 allow you to submit to Windows Store.

But even still - my app is sideloaded and never needed to care about .NET Native at all.

Workarounds are not official support and won't fly for many customers deciding what to place in production when picking technology stacks, so the choice ends up being C#, VB, C++, Rust, JavaScript and Python.

The official set of programming languages getting UWP support as part of Project Reunion.

WinUI / Project Reunion is just a continuation of the UAP (Universal App Platform) libraries. The support for C# works for F# - just like basically any other C# library can be used from F#. I figure the reason they don't mention F# is because it is obvious and/or implied but perhaps at the same time don't want to infer there is some kind of F#/FP-style syntax.

I wouldn't confuse Project Reunion and the arbitrary Windows Store requirement that apps be compiled with .NET Native. A requirement that, frankly, is on borrowed time anyway and I can't envisage it surviving much longer. Once .NET 6 delivers Mono-style AOT support - .NET Native's sole remaining purpose will cease to exist. Not that modern hardware ever needed it. It was intended for Windows Phones.

If the choice facing us was a simple as you describe then, for example, we wouldn't have ended up building a UWP app in F# back in 2018, would we? Not everything is black and white nor zero sum.

Good luck with that reasoning when Windows 10X comes out next year.

UWP is still the future of Windows API, Reunion is only lifting it from the Windows kernel, and exposing the respective COM infrastructure on the Win32 side as well.

When I create applications for customers I don't select technologies that require me to place workarounds that might make them repent for having me there in first place.

Hence why as much as I like F#, it is never going to be an option for me, until it has a seat at the table of the official languages.

Apparently that isn't an issue in your case, so good luck with the endeavours.

There is nothing concerning Windows 10X that undermines anything I have said.

UWP is the future of Windows - correct.

I'm not sure any significant part of UWP has ever been in the kernel per se.

It sounds like you're a consultant where taking risks on behalf of your customers, no matter how small or logical the risk, is obviously not part of your job description.

Your offerings of good luck appear to be disingenuous.

We've been running F# in production since 2014 - almost 7 years. It is quite shocking to hear anyone imply that F# is not ready for production use - that it is just "cool" tech. (when has F# ever been cool in the minds of the masses?)

I suspect you'll say "7 years is nothing" and maybe it is nothing. But it is still something. It is long enough that we made a couple bad framework/library dependency choices early on and to have learnt lessons from such mistakes.

By far the biggest technical challenge we've faced in that time is the .NET 5 migration - but even that might turn out to be a lot easier than I currently envisage.

On the context of Windows GUI frameworks and UWP, no it isn't ready.

Still no VS or Blend tooling support, no project templates and .NET Native requires workarounds with stuff that most corporate enterprise developers don't care to learn.

Picking F# over official supported languages has zero value on the sales of customers, that is what they care about, not cool software stacks.

So if their IT goes down and the reason is that a risky loving consultant used unofficial workarounds, I rather not get unnecessary phone calls.

As for the wishing luck, I was being honest, take it as you wish.

Hopefully F# gets big enough that people will write those libraries - I think people deserve a better Python.

Interesting in the ML space is https://diffsharp.github.io/ which is heavily developed by Don Syme at the moment.

Reply on news.ycombinator.com