Why F#?

There was a large group of folks that left Ruby on Rails for Elixir (even has a similar looking syntax), yet it wasn't on your list of languages to consider. Just curious, was there a particular reason?

I should have mentioned in the message, but I was looking for a strongly typed language. I was an avid-user of dynamically-typed languages, but that particular Ruby on Rails app became unmaintainable, and part of the culprit was due to the dynamic typing. I hoped that using a statically typed language would make it easier to maintain a complex app in the long term. And I must say that it totally materialised, to the point that I don't want to develop in dynamically typed languages anymore.

Here's an example: as I said in my original message, I was a complete stranger to the dotnet ecosystem, and I learned the F# language at the same time. And I decided to develop the app as a library project to be used by the web app. I completely missed the prevalence of the async approach in the dotnet, and all my code was synchronous. One day, about half-way in the project, I realised I needed to switch to async code. Had this happened in a dynamically typed project, it would have been hell for me. Maybe it's me that can't grasp a project well enough, but I need the type-guardrails to find my way in large refactorings. And with the strong types, large refactorings can be done confidently. They don't replace tests, but make the refactoring process much more smooth.

The app is open source and its code is at: https://gitlab.com/myowndb/myowndb It doesn't have a lot of users, not the least due to lack of marketing and polishing the user experience. But I am satisfied of what I learned developing it!

These days there's Gleam[0], as a strongly typed alternative for the BEAM virtual machine. Of all the languages I haven't used yet, it seems to hit the safe + minimalistic + productive sweet spot the best. (Yes the C-inspired syntax is slightly off-putting, but syntax is the least important aspect of a language.)

[0]: https://gleam.run/

I am also keeping an eye on gleam! I also regret that they left the ml syntax behind, but as you say it shouldn't be a blocking factor. If they adopt computation expressions and make otp a priority it would probably come beside fsharp in my toolbox!

This is a really minor point, but "strongly typed" and "statically typed" are not interchangeable terms. In the context of your comments here, you are exclusively interested in the static nature of the type system, rather than anything about the "strength" of it (which is something totally different and inconsistently defined).

You are absolutely right. Thanks for pointing it out.

Gleam, much like any language which primarily targets BEAM, is slower by an order of magnitude or two when compared to F#.

Sure thing. Cheers!

The appeal is the runtime model. I can’t readily verify if BEAM languages are meaningfully slower or really slower at all but let’s take the premise for the sake of argument.

Even if is slower, the runtime model is incredibly resilient and it’s cheap to scale up and down, easy to hot update, and generally does asynchronous work extremely well across a lot of different processes.

F# has really good async ergonomics but it doesn’t have the same task/processing flexibility and Websockets are kind of a pain compared to elixir or even erlang

Hey, thank you for sharing your app's source code. I'll definitely check it out, I was really looking for such apps on F# open source projects!

Can you explain more about strongly typed vs statically typed?

strong typing: 2 + "2" is an error (e.g. Python vs JS)

static typing: 2 + "2" does not compile/parse (e.g. Python vs mypy, Typescript vs JS)

this is a very simplistic example, but should get you to feel the difference.

Typically, "static typing" refers types being checked at compile time rather than runtime; in other words, the analysis can happen before the program is run, which gives you some degree of confidence in what the behavior will be when actually running it. The opposite of this is "dynamic typing", which means that the type-checking happens while the program is running, so you don't have the up-front guarantee that you won't end up having an error due to the wrong type being used somewhere. In practice, this isn't a strict binary where a language has to be 100% static or 100% dynamic. For example, Java is mostly statically typed, but there are some cases where things are a bit more dynamic (e.g the compiler allowing certain casts that might not end up being successful at runtime, at which point they throw an exception). On the other hand, Python traditionally has been a dynamically typed language, but in recent years there have various efforts to allow type annotations that allow checking some things in advance, which moves it a bit in the static direction (I'm not familiar enough with the current state of things in the ecosystem to have any insight into how much this has moved the needle).

On the other hand, "strong typing" isn't as quite as standardized in type systems terminology, but broadly speaking, it tends to be used to describe things like how "sound" a type system is (which is a well-defined concept in type systems theory), whether or not implicit type coercions can occur in the language, or other things that roughly translate to whether or not its possible for things to get misused as the wrong type without an explicit error occurring. Two examples that are commonly cited are JavaScript[0], with its sometimes confusion implicit conversions to allow things like adding an empty object and an empty array and getting the number 0 as the result (but not if added in the other order!) and C, with it being possible to interpret a value as whatever the equivalent underlying bytes would represent in an arbitrary type depending on the context its used.

[0]: I normally don't like to link to videos, but this famous comedic talk demonstrating a few of these JavaScript quirks is so thoroughly entertaining to watch again every few years that I feel like it's worth it so that those who haven't seen it before get a chance: https://www.destroyallsoftware.com/talks/wat

weak typing: 2 + "2" is 22

.NET's SignalR is actually quite good. Strongly typed message hubs on the server[0]. Wide client support. Azure SignalR[1] if you don't want to own the infrastructure to scale web sockets.

[0] https://learn.microsoft.com/en-us/aspnet/core/signalr/hubs?v...

[1] https://azure.microsoft.com/en-us/products/signalr-service

For most of the workloads you’re putting on the BEAM, they are IO bound and this is not of any consequence

could also be "4" or 4! 4 seems like it would be the most evil option, honestly

The real evil option is C: 2+"22" = 0, 4+"4" = undefined behavior and probably the value of some other variable.

I think you meant: "22"+2 = "", and it is not UB to make the second pointer, only to use it

The real horror is "1d9" + 1 = 2, as does PHP: https://3v4l.org/Dn6Sm

> static typing: 2 + "2" does not compile/parse (e.g. Python vs mypy, Typescript vs JS)

I think this example is not correct, because static typing doesn’t affect how values of different types interact. And while I don’t know of any staticly typed language where specifically `2 + “2”` is a valid expression, statically typed languages definitely can be weakly typed: the most prominent example is C where one can combine values of different types without explicitly converting them to the same type (`2 + 2.0`).

I believe strong/weak and static/dynamic are orthogonal. And my examples are:

- Strong: `2 + “2”` is a error,

- Weak: `2 + “2”` makes 4 (or something else, see the language spec),

- Static: `var x = 2; x = “2”` is an error,

- Dynamic: `var x = 2; x = “2”` is fine.

given this is about F#, the question is how ergonomic is it to use this in F#?

In the past, I found it wonky

or the most sane, depending on context... e.g. awk and perl do this.

Dynamic typing can forbid the latter (at runtime), but it's implementation dependent. There's a further distinction, Latent typing, which is where types are associated with values rather than variables.

But a dynamic language can have types associated with variables, and it can forbid changing those types after their types have been checked the first time.

> But a dynamic language can have types associated with variables, and it can forbid changing those types after their types have been checked the first time.

So, like C++ with `auto`?