Re:The Rust I wanted had no future
by jjtheblunt on Monday June 05, 2023 @08:25AM
(#36195265)
Have you dismissed F# ?
[ Parent
| on HN ]
Re:The Rust I wanted had no future
by FrustratedMonky on Monday June 05, 2023 @08:28AM
(#36195290)
I would like to second F#. It seems to have a lot of what people want, so why isn't it more popular?
Can I natively build self-contained binaries? One of Go's biggest advantages is the delivery chain from code to server (build for target arch, copy to target, ./run)?
I believe you can https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...
Re:The Rust I wanted had no future
by throwaway2037 on Monday June 05, 2023 @11:20AM
(#36197489)
I can vouch for it! I returned to C# for a tiny desktop GUI recently. I was blown away by how simple is the tooling to create a single monolithic binary. It's great for enterprise distribution. "No more installer."
Re:The Rust I wanted had no future
by jjtheblunt on Monday June 05, 2023 @09:13AM
(#36195711)
Yes
Re:The Rust I wanted had no future
by ontologiae on Monday June 05, 2023 @10:42AM
(#36196843)
I had to deal with it, when I hadto parse Transac-SQL code, and it's not handy. Very difficult to have a single executable file containing everything, it needs a whole subtree.
OCaml is easier with Opam and ocamlbuild tools.
Unfortunately a lot of people will dismiss C# and F# just because it has the Microsoft label. I do think they're missing out.
Nowadays I program in a mostly Microsoft world (VSCode, Github, npm, typescript, GPT, ...) and I think its quite good, so no bias here. But the "shipping a native binary straight to the server that just works" is absolutely crucial for me
.net will let you do that now. You can ship precompiled binaries with Native AOT. (https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...)
And even before native AOT you could use publish single and have a single binary.
ASP.NET AOT support coming in .net 8
The rest of the world has. If you're going to use .net, there's almost zero chance that you'll get permission to use F#.
For whatever reason, C# devs seem incredibly resistant to even just looking at F#.
Do you want reasons? Here are a couple from someone that has learned ML with Caml Light, and most of the latter ML variants.
VS Tooling lacking versus C#/VB, no support for code generators, no support for Roslyn, no support for GUI frameworks, no support for EF tooling, many .NET vendors don't support projects if using F#, community likes to create their own wrappers instead of embracing standard .NET projects, ....