Hacker News Reader

Comment by darksaints | Hacker News Reader

So...I think a decent choice to make here is to switch from OCaml to F#. You'll get almost all of the benefits and most of the drawbacks go away. And for the most part, you can directly translate the code from OCaml to F#.

The big reason to not use F# vs OCaml tends to come down to the lack of functors... but it looks like your current codebase might not be using them much.

View on HN

I enjoy f# a lot, but it doesn't necessarily help with all of their problems.

One of the biggest problems they mention is with postgres. F# has a postgres problem as well.

Your options in f# for postgres usage include the following high-level categories:

• Dapper/RepoDb/Other community libs

• Typeprovider based like Fsharp.Data.Npgsql

• EF core (where you build the fsharp design-time support yourself)

• Using C# in another project as a database interaction abstraction

I've had to mix and match for the projects I've worked on because I've had trouble finding a single library where:

1) Joins are supported in a sane way

2) Batch inserts work

3) Interacting with native features (views, functions, SET variables) works

4) It's still in fsharp

It's not bad, but when I work on $DAYJOB projects in Typescript/etc where database access is smooth, I wonder how long it might take to rewrite for the database heavy projects.

Also should mention that I'm very thankful for the libraries that _do_ exist, and the effort put into making them as feature as they are. It's just one of the areas that I don't think is a strength of F# right now.

But those are all database abstraction mechanisms or ORMs. Regular SQL access to postgres databases is pretty much a fully solved problem in F#, even if the ORMs are not.

This is true (with the caveat of some interesting edge-cases with npgsql and F#), however the next paragraph in the article mentions "a lack of a high-level, production web stack".

Definitely a personal take here, but since I've worked for a while with postgres, a "high-level, production web stack" for me is something that has an established, good DX way to work with this popular database.

Managing ADO.NET connections, working around the type systems and writing a lot of mapping/connecting code are all things that don't solve my business problem.

While not prolific, I've written a handful of production web applications in F# (Suave, Giraffe, Saturn, and Razor Pages) as well as other stacks, and have found a hybrid approach that works for my concerns, but I've found a comprehensive solution not as simple as other ecosystems.

I'd love to read through some production Saturn and Giraffe setups - is any of your stuff public?

Unfortunately almost all of my work is not public. I've always envied folks with lots of public code to show and share. I had created an F# starter-kit repo (somewhere between hackathonstarter and bullet-train saas kit) along with some blog posts, but I just haven't had free time to wrap it up and publish the repo/blog posts.

I see questions frequently about data access and serialization/validation in F# web apps, which I had specific sections about. Hopefully I'll have some time in the near future to continue the work.

In the mean time feel free to DM me any questions. There's nothing too fancy about the code. If you looked at other production code, and swapped out what your best guess for the F# translation would be, you're probably most of the way there.

are you freelancing by any chance? dm me on twitter at same username

We're using Giraffe and it's great. The nice thing IMO is that is sits on top of ASP.NET core. So it's fast and if you need something like SignalR, ... it integrate flawlessly.

Have you looked into Linq2Db [0]? (I'm a contributor to the project) I know a few F# users have had success with a couple of minor caveats. I can say it handles most of the points you mentioned fairly well however (Great join syntax, lots of bulk insert options, easy wire-in for native features.)

[0] - https://github.com/linq2db/linq2db/

It's been a while since I looked at linq2db, but it looks like a great project. I'll probably carve out some time this weekend to play around with it!

I've done quite a bit of F# Postgres in a previous life and I didn't find it much different than other programming languages. However I tend to just use the Npgsql library directly with ADO.NET for performance which I often needed for my cases with Postgres. These days you can insert array objects, insert whole objects graphs, do batch inserts and create little helpers to read/write sets with Npgsql/PSQL directly; often much faster than using a higher level ORM. In my experience Postgres often would produce query plans that required a lot of SQL tuning/rewriting in a different way to get right (e.g. loose index scan SQL to get latest entry per group). I just wrap the solution/build with DB tests to make sure the SQL is covered well vs using the type provider. Tbh the amount of code (in lines) is mostly the same as well to do it vs a higher level framework - we did the comparison.

maybe you should give this one a try: https://github.com/rspeele/Rezoom.SQL

We've been using https://github.com/Zaid-Ajaj/Npgsql.FSharp and it's great. Uses well supported lib behind the covers and just provides a small layer on top.

Same thing exists from MS SQL https://github.com/Zaid-Ajaj/DustyTables , also great.

Used both in prod. No regrets and wouldn't wan't something else. Also involves zero magic - just raw SQL and a nice functional API.

I also had a good experience with Npgsql.FSharp. I love that it is just an idiomatic F# layer on top of raw SQL. I don't think that ORM is a good fit for functional languages anyway.

I believe there is some work with F# analyzers to provide compile-time checking of raw SQL, although I haven't tried it yet.

agreed. Often dealing with an ORM is more complex than just to write a bit of SQL and reading code.

Yep, never tried it either. https://github.com/Zaid-Ajaj/Npgsql.FSharp.Analyzer

If you're writing a while platform with a new ide concept, built in deployment and your own framework on top. (darklang) I think an ORM is the least of their problems.

They'll not going to pick F# because they're in competition with Azure.

They don't want ocaml because of marketability. It's technically the right choice and direction but the learning curve for developers is turning them off the platform as a whole.

I tried doing that for my program and failed miserably, mostly because CLR is not optimised the same way the OCaml runtime is optimised to minimise copying of memory. As a result the (direct translation of the) program became more than 5 times slower, which was a deal breaker for this use case.

Yes, there are ways to write it in a .NET-y way in F#, but then it requires a "complete" rewrite and F# gives no real benefits with "being similar".

In contrast, after that I migrated to Rust and I am delighted. I wrote about it here: https://news.ycombinator.com/item?id=24893285

Of course, this is also a full-rewrite without using the same idioms as in OCaml (mostly because I mutate objects directly when needed) but I still think it's much better than F# as the language (Rust) is miles ahead in the practicality domain. Indeed, it's much better than anything I've seen so far. And still so very much "functional" and "elegant". I just miss the transparent currying from OCaml.

> You'll get almost all of the benefits and most of the drawbacks go away.

That's a bit overstatement. You can call .Net code from F#, just like you can call Java from Clojure or Python/Rust/C from OCaml.

It just would be foreign and unidiomatic (hello, null pointers, methods, OOP).

And you can call C/Python/Rust from OCaml, we made quite a lot of wrappers for Gstreamer and some Rust libs in OCaml and it was quite painless.

So it's a bit of simplification, you can call foreign code in OCaml, it's not that much harder than F# considering there are higher level FFIs for C, Rust and Python available. Author could just use these as well.

Writing an F# wrapper for a C# API is considerably less involved than writing an OCaml wrapper for a C API.

This is because F# and C# share:

* build tools

* package management

* garbage collector

* base types (string, int, etc).

The F# type-checker understands C# types, so you know that you are consuming the C# API correctly (at least at the type-level). F# can be be used as a new syntax for C#, if you wanted to go that way.

More interestingly you can also go the other way if you use only the lower level F# features (F# being mostly a superset of C# features) and a C# developer won't realise that they are calling F# code - it's all just .NET IL in the end. Did it often when creating libraries at work; it isn't like invoking another language's binary code at all. One of the pro's I guess of working with a VM (JVM/.NET) based language - interop between languages is usually much easier and so niche languages can have a much larger ecosystem than they otherwise would have.

I was thinking the same all throughout the reading. I've been using F# on GCP in production for 3 years now and it's fantastic and only getting better. You can leverage existing .NET libraries (for example, you get official GCP libraries from google) and if you use them enough it's easy enough to write a functional wrapper around them. I recently rewrote the frontend using Fable.React so that I can share code between backend and frontend.

> The big reason to not use F# vs OCaml tends to come down to the lack of functors...

What do you mean by that? F# has support for functors, or are you referring to something else? https://fsprojects.github.io/FSharpPlus/applicative-functors...

Those are an implementation of functors as they exist in Haskell. The functors I'm talking about are actually a language level construct that is a primary abstraction mechanism in OCaml/SML. They are essentially higher-level modules: modules that are parameterized by other modules.

https://stackoverflow.com/a/16353711

Can someone explain to me like I'm 5 what the big deal about functors is?

Probably not, as it is a very abstract generalization for what is essentially a simple concept that for most purposes doesn't need a math-y abstraction. And it would depend on whether you're talking about Haskell, or OCaml, or Category theory.

The best I could describe the general concept is that a functor allows you to take something of some type and maps it to another type via some unspecified function.

If you mean ML (i.e. OCaml) functors, then to put it simply: they are the primary code abstraction mechanism in ML. ML doesn't have inheritance and runtime dispatch, instead it uses functors which do static dispatch.

Simple example: in an OOP language you might have a Map<K, V> class for any type K, V where K must be an instance of an Ordered interface so that the map implementation can do efficient lookup.

In OCaml, you have a Map.Make(Ord : Ordered) functor which explicitly takes a module Ord as its parameter. The Ord module implements the key data type, which must support the Ordered interface. When you (statically) apply the functor, you get back a new module which specializes a map data type to work for the specific key type. E.g.,

    module StringMap = Map.Make(String)

The String module implements the Ordered interface, so it can be used as the argument here. Now you can create and manipulate maps of strings to any values.

You might be wondering, what's the payoff? It's very similar to the payoff for interfaces--code abstraction. It's just that it's all statically resolved and highly efficient.

Sounds like this is covered by F# already, simply by the use of genercs (similar to what you described for OOP, which in that particular case doesn't really have any OOP downsides, i.e.: no inheritance, no state).

>simply by the use of genercs

It depends on what you mean by "generics". Functors are generics, but very powerful ones, akin to packages in Ada.

They are way more generic than what parametric polymorphism allows you to do in F#, they support Higher Kinded Types, module can have many type variables within it etc etc.

In F# you have List<'a> but you cant have a single map operation abstracting over Lists, Arrays, Options..... so they have to be implemented separately Option.map, Array.map.....

Not just with generics, but also with dynamic dispatch on the runtime class of the K type which implements Ordered interface. ML traditionally doesn't have dynamic dispatch, so it uses the static mechanism of building a map type specialized to a given key type. The value type is completely generic, though.

I said 'traditionally' above because OCaml actually has dynamic dispatch now; it has a powerful and feature-complete OOP implementation, and a way to pass around modules at runtime as first-class objects. And in fact people take advantage of these capabilities to build more 'modern' APIs. But I would argue that the functor approach is one of, if not the best, overall.

He's talking about functor from OCaml and SML which are basically a function in the module level. So a module which take other modules as arguments and produce a new module.

In OCaml, "functors" are parametrized modules—mostly unrelated to functors and applicatives in the Haskell sense. Think about it as a module that can take another module as an input.

OCaml functors are not the same as Haskell/F# functors/applicatives (which are essentially one and the same in OCaml if you use named arguments).

Instead, they're roughly "functions from modules to modules": https://dev.realworldocaml.org/functors.html. Functors allow you to replicate much of what classes/objects in an OO language offer, but with static instead of dynamic dispatch.

I am an F# person rather than OCaml and am not familiar with the compiler, but this seems to be overstating the difference: I thought the OCaml functors are “real” mathematical functors that implemented a structured type polymorphism over the “input type” - they look pretty similar to C++ templates superficially but they work similarly to Haskell type classes. They are “functions from modules to modules” but those functions take types as values.

Real experts should let me know if I am mistaken: I don’t think OCaml and Haskell have strictly the same type system, but they are both similarly more expressive than F# because of this specific type -> type polymorphism that in particular lets you do type-checked monads, etc.

Neither Haskell's nor OCaml's functors are the same as the mathematical one I believe, but both are similar in some way that the word makes sense to be used for their respective feature.

In OCaml, functors map between an abstract module and some concrete one. And in Haskell functors are structures that can have a function that maps over their elements. In math a functor is a map between categories. So you can see how all three kinda make sense as functors, but also are different in exactly what they are.

Both Haskell's and OCaml's functors are special cases of the general mathematical one.

How? What are the categories that OCaml's Hashtbl.Make maps between? What are the morphisms in those categories and how are they mapped?

It maps between a category with HashedType implementations as objects and a category with Make implementations as objects. Unfortunately it's not a very interesting functor because to satisfy the functor laws I think the categories have to be discrete. It's basically a function! (And functions are indeed a special case of functors.)

https://caml.inria.fr/pub/docs/manual-ocaml/libref/Hashtbl.M...

Right, in other words it is just a function. I don't think the categories have to be discrete just to satisfy the functor laws; even ignoring that, what would the morphisms be in principle? I don't think there is an obvious choice, at least.

I think in OCaml, "functor" basically just means "like a function but for modules". They might technically be categorical functors, but it seems quite different to the meaning in Haskell where they are plainly categorical functors (modulo Hask technically not being a category).

Agreed, I'm not sure it's a terribly interesting functor.

Here is one way one might implement a categorical Functor (https://www.reddit.com/r/haskell/comments/eoo16m/base_catego...).

A function S -> T maps a S(ource) type to a T(arget) type, like FunctorOf (-S>) (-T>) does between the source category (-S>) and target category (-T>)

    type  Functor :: forall (s :: Type) (t :: Type). (s -> t) -> Constraint
    class (Category (Src f), Category (Tgt f)) => Functor (f :: s -> t) where
      type Src (f :: s -> t) :: Cat s
      type Tgt (f :: s -> t) :: Cat t
      fmap :: Src f a1 a2 -> Tgt f (f a1) (f a2)

    type FunctorOf :: forall (s :: Type) (t :: Type). Cat s -> Cat t -> (s -> t) -> Constraint
    type FunctorOf src tgt f = (Functor f, Src f ~ src, Tgt f ~ tgt)

The usual endofunctor

    type EndofunctorOf :: forall (ob :: Type). Cat ob -> (ob -> ob) -> Constraint
    type EndofunctorOf @ob cat f = FuntorOf @ob @ob cat cat f

we have in Haskell can be defined as FunctorOf @Type @Type (->) (->), or

    type OldFunctor :: (Type -> Type) -> Constraint
    type OldFunctor f = EndofunctorOf @Type (->) f

For simplicity written with a type synonym, but it cannot be partially applied. So I would use constraint synonym encoding (https://gist.github.com/Icelandjack/5afdaa32f41adf3204ef9025...)

    type FunctorOf :: forall (s :: Type) (t :: Type). Cat s -> Cat t -> Constraint

    class    (Functor f, Src f ~ src, Tgt f ~ tgt) => FunctorOf src tgt f
    instance (Functor f, Src f ~ src, Tgt f ~ tgt) => FunctorOf src tgt f

The other definitions can be eta reduced

    type EndofunctorOf cat = FunctorOf cat cat
    type OldFunctor        = EndofunctorOf (->)

I was thinking the same thing. Using multicores and having a library ecosystem (through interop rather than conventional F#) should be a win. I don't have an idea what performance difference to expect but certainly closer to OCaml than Python even for single-core.

At least as of a couple years ago, OCaml wins on performance for anything single core, but not by much. F# is usually within a 5-10% performance gap. Absolutely better than Python.

I don't think that's accurate. The Benchmark game [1] shows F# winning more and by larger margins. My own benchmark [2], which was reimplementing Dark in three languages, had F# with 2x the throughput.

(standard caveat that benchmarks suck)

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[2] https://github.com/darklang/fizzboom/issues/13

Interesting, they have definitely closed a lot of gaps since I last used it.

I think .NET Core (esp v5) has had lots of good performance work: https://devblogs.microsoft.com/dotnet/performance-improvemen...

Reply on news.ycombinator.com