[tasuki]

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/

[neonsunset]

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

[no_wizard]

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

[CharlieDigital]

.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

[no_wizard]

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

In the past, I found it wonky

[davydog187]

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

[raphinou]

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!