5 ms·

> I feel like the compiler was my teacher, and it kept on teaching me new concepts to look up in the docs. I work primarily in F#, a functional .Net language,

> I feel like the compiler was my teacher, and it kept on teaching me new concepts to look up in the docs. I work primarily in F#, a functional .Net language, which also enforces strict rules at compile time to ensure correctness... With the benefit of experience it's amazing and comforting and lets you reason happily about applications at a higher level. It's on of my favorite parts of the language, TBH. And while I see its strength over time, and see the benefit it gives to code bases, I also know that for your average C# dev used to firing up their app and debugging at run-time, or working in certain ways with their code, it feels like putting on a straight-jacket. It hurts the "first week" story to the benefit of long term concerns. I totally agree: it's forced learning, which makes it a bit of a grind. But damned if I'm not a much better programmer for the effort :)

pjmlp 9y ago
F# is nice, if only Microsoft would actually provide feature parity with C#, VB.NET and C++ tools. I bet C# will sooner copy F# features than Blend, GUI designers or .NET Native will support F#.
- bonesss 9y ago
  That response is kinda offtopic for Rust... but: F# is a first class .Net language that interops rather well with the others... If you have some burning need to use Blend or a GUI designer then you can always have a C# shim feeding into an F# domain/core with little problem. It's the same interop story as VB.Net, fundamentally. That said: if you track MS's track-record those technologies and their Enterprise market viability, outside of resume-driven-development there isn't a lot of reason to be throwing hard money at their new shiney shiney... C# lags drastically behind F# in areas not focused on the client: scientific computing, cloud computing, parallel computing, agent/actor systems, etc... Being a release cycle off on the coolest new drag-n-drop tooling from MS is a moderating influence that has created a much better cross-platform story, and OSS story, for F# than C# has ever achieved, despite the scale difference. Oh, and C# has been actively trying to copy F# for many release cycles, including reworking basic language design decisions... It is, however, fundamentally unable to achieve that goal based on the languages overriding design. I'm impressed they're back-working non-nullable value objects, for example, but the language can't give guarantees that ML languages can. Pattern matching is nice, but exhaustive pattern matching is what you want for hard things, IoW. And those deficiencies make C# a non-starter or also-ran for a lot of the BigData, streaming, cross-platform systems you see in big data halls and scientific computing. It's almost like different tools are good for different things ;)
carlmr 9y ago
I went to F# from C#, but I felt the transition was easier than going from C to Rust. I kind of noticed that I used some functional concepts a lot in my C# anyway. I always liked side-effect free functions, I tended to do a lot with LINQ transformations already, etc. F# made a lot of these things nicer to use (+ pattern matching + discriminated unions +++)
- bonesss 9y ago
  The two languages are approaching a superficial parity, as C# eats up more and more functional concepts. I find it interesting, too, because many of the arguments about things being 'too hard' compared to C# make no sense when those concepts are baseline knowledge in both languages. The positive parts of the functional approach will make code more solid in any language, and C# is working hard to support that approach :) I've got over a decades C# experience, and it's readily one of my favorite pragmatic languages for real-world work. MS has done an exemplary job of actively and aggressively improving the language. That said: barring the sole use case of trying hot-new-tech from microsoft, I never pick it up anymore... My F# code is always more concise, smaller, more robust, and provides execution guarantees that save me metric buttloads of work and testing. The scripting support kills any need for those Python utility scripts. Type providers give structural guarantees to handling external data, and proper use of Discriminated Unions empowers meaningful domain modelling better than anything I've seen. It's also unusual to me, with... well... a dogs age in the industry, to find myself compelled to open up projects from 6+ months ago just to stare at how deeply pretty some of my algorithms are. So pretty that if git didn't blame me, I'd have to conclude someone else wrote them ;)
  - carlmr 9y ago
    I agree. I just wish more other people knew F# so I could use it for more projects. I've also almost stopped using Python for my scripting purposes. F# is just so much more elegant, and if the scope of the script grows, I can grow it to a proper project. The only reason why I still use Python every once in a while is pandas. If I have to analyze some big tables, it's still far ahead of anything in any other language I know. Sadly F# Deedle feels very clunky, especially when processing a lot of text (which my data frames are usually full of).

pjmlp 9y ago

F# is nice, if only Microsoft would actually provide feature parity with C#, VB.NET and C++ tools. I bet C# will sooner copy F# features than Blend, GUI designers or .NET Native will support F#.

bonesss 9y ago
That response is kinda offtopic for Rust... but: F# is a first class .Net language that interops rather well with the others... If you have some burning need to use Blend or a GUI designer then you can always have a C# shim feeding into an F# domain/core with little problem. It's the same interop story as VB.Net, fundamentally. That said: if you track MS's track-record those technologies and their Enterprise market viability, outside of resume-driven-development there isn't a lot of reason to be throwing hard money at their new shiney shiney... C# lags drastically behind F# in areas not focused on the client: scientific computing, cloud computing, parallel computing, agent/actor systems, etc... Being a release cycle off on the coolest new drag-n-drop tooling from MS is a moderating influence that has created a much better cross-platform story, and OSS story, for F# than C# has ever achieved, despite the scale difference. Oh, and C# has been actively trying to copy F# for many release cycles, including reworking basic language design decisions... It is, however, fundamentally unable to achieve that goal based on the languages overriding design. I'm impressed they're back-working non-nullable value objects, for example, but the language can't give guarantees that ML languages can. Pattern matching is nice, but exhaustive pattern matching is what you want for hard things, IoW. And those deficiencies make C# a non-starter or also-ran for a lot of the BigData, streaming, cross-platform systems you see in big data halls and scientific computing. It's almost like different tools are good for different things ;)

carlmr 9y ago

I went to F# from C#, but I felt the transition was easier than going from C to Rust. I kind of noticed that I used some functional concepts a lot in my C# anyway. I always liked side-effect free functions, I tended to do a lot with LINQ transformations already, etc. F# made a lot of these things nicer to use (+ pattern matching + discriminated unions +++)

bonesss 9y ago
The two languages are approaching a superficial parity, as C# eats up more and more functional concepts. I find it interesting, too, because many of the arguments about things being 'too hard' compared to C# make no sense when those concepts are baseline knowledge in both languages. The positive parts of the functional approach will make code more solid in any language, and C# is working hard to support that approach :) I've got over a decades C# experience, and it's readily one of my favorite pragmatic languages for real-world work. MS has done an exemplary job of actively and aggressively improving the language. That said: barring the sole use case of trying hot-new-tech from microsoft, I never pick it up anymore... My F# code is always more concise, smaller, more robust, and provides execution guarantees that save me metric buttloads of work and testing. The scripting support kills any need for those Python utility scripts. Type providers give structural guarantees to handling external data, and proper use of Discriminated Unions empowers meaningful domain modelling better than anything I've seen. It's also unusual to me, with... well... a dogs age in the industry, to find myself compelled to open up projects from 6+ months ago just to stare at how deeply pretty some of my algorithms are. So pretty that if git didn't blame me, I'd have to conclude someone else wrote them ;)
- carlmr 9y ago
  I agree. I just wish more other people knew F# so I could use it for more projects. I've also almost stopped using Python for my scripting purposes. F# is just so much more elegant, and if the scope of the script grows, I can grow it to a proper project. The only reason why I still use Python every once in a while is pandas. If I have to analyze some big tables, it's still far ahead of anything in any other language I know. Sadly F# Deedle feels very clunky, especially when processing a lot of text (which my data frames are usually full of).