51–60 of 130 posts
Earlier quoted context omitted.
Node has its place, i wouldn’t call F# an alternative to it. The node community is absolutely fantastic. F# is also an amazingly powerful language and im happy using it on the back end
What is Node's place?
OO in F#. there goes the language...
OOP is not idiomatic F#. It is mostly for interop with C#.
You are right, however, that OOP should not be the default way to write things in F#.
Earlier quoted context omitted.
C# was usable in VS Code even 3 years ago
How is it these days? Is it “usable” or actually something you want to and enjoy using? Will I be left wanting Visual Studio? I mean I really enjoy IntelliJ, it makes programming Java like slicing butter. But I do want to try F#, people talk so highly of it.
F# is a joy to use. After a certain time, many C# developers find themselves writing in a functional style. F# makes this the default, but lets you continue using all of your existing code. Better yet, Linux and macOS support via .Net Core is excellent. F# on .Net Core is now a powerful alternative to Node.js.
If you can't move to F# or find its tooling abysmal and slow then I have a library [1] that makes the inertia flow positively in the functional direction in C#
Earlier quoted context omitted.
It's almost to the point where the deciding factors in choosing between (C#-style) OOP and (F#-style) FP are: - Do you want your data types in one line or 20? - Pattern matching, or large concretions of if-statements? - Race conditions: Quality problem, or fun puzzle?
C# has most of the same pattern matching functionality at this point
C# has support for most F# features, they're just often awkward to use
I think several interesting points were brought up in this thread regarding the assumption of functional aspects presented in F# by C#. LINQ being the most popular example. I am currently lead to believe that a purely functional application development domain is potentially an overreach of theory in terms of building things that can interact with the real world in very complex and 'functionally-leaky' ways. My biased…
I just bought Scott's book on Railway Oriented Domain Driven Design. So far so good. I am the domain expert though, so no revelation there. The modeling of state machines using types and functions is pretty revolutionary to me for where I'm currently at development skill wise. Everything just seems so clean and elegant.
I used to be a big Haskell programmer. While I still love the language, I've really come around to the idea that strictly evaluated functional languages like F# or OCaml are the best for programming in. You get the nice functional features but don't have the straightjacket of laziness forcing you into certain design decisions. It's really nice sometimes to be able to mix in impure, side effectful code without having…
Additionally, on cases where you’re not specifying the data of the type itself, you can use static type constraints on members. This doesn’t give you a default implementation like Haskell but you can always provide one as a function.
Btw the monadic threading is still very useful, especially when mixing impure code and mutation (when appropriate). The async and result monads, in F# computation expression form, are particularly useful.
For a good example of async + impure code, check out MailboxProcessor, which is part of the standard F# lib. Works similar to CSP/goroutine + channels/actor models; makes parallelized concurrency and message passing easy. You can also make pure mailboxes easily by recursively passing data forward, but sometimes you don’t want to for memory / gc & alloc reasons.