3 ms·
Gleam, much like any language which primarily targets BEAM, is slower by an order of magnitude or two when compared to F#.
by neonsunset 2y ago
Gleam, much like any language which primarily targets BEAM, is slower by an order of magnitude or two when compared to F#.
- no_wizard 2y agoThe 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 2y ago.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?view=aspnetcore-9.0#strongly-typed-hubs https://learn.microsoft.com/en-us/aspnet/core/signalr/hubs?v... [1] https://azure.microsoft.com/en-us/products/signalr-service https://azure.microsoft.com/en-us/products/signalr-service
- no_wizard 2y agogiven this is about F#, the question is how ergonomic is it to use this in F#? In the past, I found it wonky
- davydog187 2y agoFor most of the workloads you’re putting on the BEAM, they are IO bound and this is not of any consequence