4 ms·
> The C# of my day job often feels like banging rocks together with its c-style enums and lack of sum types. Hah, I agree. I switched over to F# and never look
by munchler 4y ago
> The C# of my day job often feels like banging rocks together with its c-style enums and lack of sum types.
Hah, I agree. I switched over to F# and never looked back. It plays nicely enough with C# that my colleagues couldn't stop me (but didn't join me either).
> But there is always an article about go that makes you appreciate what you do have.
Yes. Go seems like a time machine back to about 1985.
- OliverGilan 4y agoStarting a new project and trying to decide between Go and F# of all things. Go seems fast and very widely used which means resources and help is widely available and it’ll be easier to find contributors. Meanwhile coming from the C# world at my job I really like the syntax of F# from what I’ve seen so far. The type system seems incredibly expressive in a way Go’s isn’t, access to C# libraries means I can do pretty much anything I’ll need to, and I enjoy FP paradigms even though I’m not looking for full FP (I generally like loops and escape hatches from FP if I need to do something specific). What’s your experience with F#? I’m worried about support and finding other people familiar with the language, not a huge fan of nuget, and I prefer to use VSCode but C# has been impossible to program in VSCode imo.
- munchler 4y agoI’ve had a great experience with F#. It’s now my preferred language in almost all cases, and it’s plenty fast enough for the vast majority of applications. I use Visual Studio and the UX is excellent. (A lot of F# developers use Paket instead of Nuget.) MS seems committed to F# as at least a source of future C# language enhancement ideas (although C# will never fully catch up). There’s also a vibrant F# community on Stack Overflow, Reddit, etc. I never have trouble getting help if I need it.
- pjmlp 4y agoUnfortunely switching to F# also means throwing away what actually makes .NET relevant in terms of end to end developer experience, and the Redmond overloads don't seem to care that much to change that, as the C in CLR seems to refer to C# and no longer to Common, in the ways VS and VS4Mac are designed.