Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why you should learn F#

dusted.codes

Post reply on HN
Print view View original

121–130 of 179 posts

Re: Why you should learn F#

#121

Post by atombender »

chusk3 wrote: post #120
atombender wrote: post #110

Earlier quoted context omitted.

Well, if not Mono, then the .NET Core runtime package, right? It's not self-contained. I read this [1], but it's unclear to me how I build a self-contained binary, or what options are available for AOT. [1] https://github.com/dotnet/core/blob/master/Documentation/sel...

If you build with 'msbuild publish -r debian8.x64' or any of the other valid 'runtime identifiers', the output of the build is an xcooy-deployable folder that contains your binary and all it's dependencies including the runtime. I use this at work to make Debian packages that are standalone.

Cool, thanks!

Re: Why you should learn F#

#122

Post by skosch »

nickpeterson wrote: post #81
smush wrote: post #57

Earlier quoted context omitted.

This has been previously mentioned but F# gets all of the goodies that come with being a .NET language. Elixir comes from Ruby land and thus has a framework called Phoenix(?) which also has its fans. The big difference is that F# is a statically typed functional language, while Elixir is a dynamically typed functional language. Comparison of static vs dynamic types -> https://hackernoon.com/statically-typed-vs-dynami…

Did you mean to say Elixir comes from Ruby? Surely you mean Erlang?

Elixir obviously is Erlang under the hood, but its syntax was inspired by Ruby's simplicity. José Valim, the creator, was also a Ruby contributor IIRC.

Re: Why you should learn F#

#123

Post by algorithmsRcool »

chusk3 wrote: post #120
atombender wrote: post #110

Earlier quoted context omitted.

Well, if not Mono, then the .NET Core runtime package, right? It's not self-contained. I read this [1], but it's unclear to me how I build a self-contained binary, or what options are available for AOT. [1] https://github.com/dotnet/core/blob/master/Documentation/sel...

If you build with 'msbuild publish -r debian8.x64' or any of the other valid 'runtime identifiers', the output of the build is an xcooy-deployable folder that contains your binary and all it's dependencies including the runtime. I use this at work to make Debian packages that are standalone.

The command you are thinking of is probably `dotnet publish -r debian.8-x64`

Re: Why you should learn F#

#124

Post by algorithmsRcool »

sparkie wrote: post #100
algorithmsRcool wrote: post #14

F# is 3 big things to me: Safer threading with immutability Safer programming with null-safety Safer logic with precise domain modeling The precise domain modeling is the real paradigm shift. The whole point of static typing is to inform the compiler about your intent so that it can provide guarantees about correctness. F# makes it easy to define lots of small types that precisely model state so that you can give mor…

One of the features that makes F# great for organization is the sequential ordering of compilation units which makes it easier to understand code dependencies, and makes it awkward to create mutually recursive types (requiring them to be in the same code file separated by `and`, or defined in signature files in advanced). This might sound like an unwanted restriction, but 9 times out of 10, having mutually recursive…

I mostly agree about mutually recursive types, but I really hate having to keep my files ordered in the project honestly.

It might be my least favorite thing about F# (Except that Option is a class not a struct)

Re: Why you should learn F#

#125

Post by thedirt0115 »

I don't know F#, but I do know C#, and it feels like the author is trying to make C# look more difficult/verbose than it needs to be to make F# look better. Here is an alternative version of the "Everything is a function" section's IPasswordPolicy thing: https://ideone.com/3Savt9 I even went a little overboard with the function that takes a list of functions and returns a single composed function -- I could've also written a one-off that uses "&&" like the F# version: bool isValidCustom(pw) { return f1(pw) && f2(pw) && ...; } Am I missing something? Why did the author make the C# version so complex??

Re: Why you should learn F#

#126

Post by analogtsar »

atombender wrote: post #118
javcasas wrote: post #113

Earlier quoted context omitted.

After being deeply burned by the .NET framework, I consider OCaml significantly superior to F# just because it doesn't depend on .NET or Microsoft. And yes, somehow the OCaml guys have managed to implement generics and AOT compilation to optimized machine code long before the .NET framework existed, but now this is something "truly hard" on .NET.

My problem with OCaml that while the semantics are top notch, everything else is stuck in the past. The syntax is quirky, there's a bunch of legacy baggage (does anyone use the OO stuff?), there's no SMP support (though I know this is being worked on), the toolchain feels antiquated (the REPL still, to this day, doesn't come with Readline support built in; rlwrap is required!), etc. Not to mention the lack of modern…

I think modern OCaml's toolchain is quite nice — Dune, OPAM, Utop, OCaml/ReasonML support for VSCode. I am a newcomer to OCaml world, but so far it's been great for me.

Re: Why you should learn F#

#127

Post by uryga »

ambulancechaser wrote: post #117
mavelikara wrote: post #109

Earlier quoted context omitted.

Why do you struggle with this in C#, especially given that you are familiar with the F# style? I don't know C#, but in Java I'd write this as: public class Order { final Optional delivery; public Order(Optional delivery) { this.delivery = delivery; } } public class DeliveryDetails { final long deliveryTimeMs; ... public DeliveryDetails (long deliveryTimeMs,...) { this.deliveryTimeMs = deliveryTimeMs; ... } } My IDE w…

that's true, you can recreate it in some sense but you can't get to what F# can guarantee. A big promise of discriminated unions is the ability to make invalid state unrepresentable. Matching on the different type constructors is a fantastic way to only express coherent states.

> Matching on the different type constructors

Terminology nitpick: Pattern matching is done on value constructors (or just "constructors", but at the intersection of FP and OOP that could be confusing).

"type constructor" means something like `List` (as opposed to `List[Int]`) – a generic type that hasn't been applied to any type argument(s) yet, and will "construct" a type (like `List[int]`) when you apply it.

Re: Why you should learn F#

#128

Post by dzonga »

Like I mentioned in another thread > Been learning F# the last two months. Wanted to learn Ocaml first. But F# is the sweet spot, beautiful functional syntax . Can leverage the now open .Net Ecosystem + pretty fast for doing financial stuff that I wanna do.

Re: Why you should learn F#

#129

Post by knocte »

atombender wrote: post #105

F# seems like such an amazing language every time I look at it — a modern version of OCaml, with a clean syntax, some novel ideas, and fewer legacy warts. However, I wish that it had, like OCaml, a native AOT compiler that didn't come with the baggage of the .NET runtime. Some people might consider this a benefit, not baggage, of course. But it's the same reason I'm put off by Scala. From what I understand, to even r…

AOT not supporting generics? that's a pretty bad reading/summary of the webpage you link to (not to mention, that page may be a bit outdates, and more cases are supported by AOT now; take in account this is the mode that iOS apps developed with Xamarin need to use).

Re: Why you should learn F#

#130

Post by algorithmsRcool »

thedirt0115 wrote: post #125

I don't know F#, but I do know C#, and it feels like the author is trying to make C# look more difficult/verbose than it needs to be to make F# look better. Here is an alternative version of the "Everything is a function" section's IPasswordPolicy thing: https://ideone.com/3Savt9 I even went a little overboard with the function that takes a list of functions and returns a single composed function -- I could've also w…

Well you're right of course. But my only thought here is that Dustin's code looks like idiomatic C#, but yours does not.

You can do function composition in C# but I've virtually (heh) never seen it. Classes and Interfaces are the default abstractions in C# land even if there are other available.

Post reply on HN