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

Why F#?

batsov.com

Post reply on HN
Print view View original

271–280 of 424 posts

Re: Why F#?

#271

Post by vlovich123 »

johnisgood wrote: post #173
vlovich123 wrote: post #127

Earlier quoted context omitted.

F# will likely remain niche forever. It’s likely that Rust will not given its growing and accelerating adoption by Microsoft, Google and the Linux Kernel. It just takes time to defeat the 40+ years of c and c++ dominance.

Personally I will always prefer C's simplicity to Rust's complexity. Could be just me.

Rust like any language can be as simple or as complex as you want it to be. The complexity raises with the performance of the code you write but that’s also true of C. Unlike C that complexity is combined with guarantees that your code won’t crash in weird and unpredictable ways.

Re: Why F#?

#272

Post by foretop_yardarm »

pimbrouwers wrote: post #46

Our shop converted 6 years ago, from C# to exclusively F#. I also author and maintain some packages (falco, donald, validus and others). The language is tough to learn if you're coming from a C-style language. But worth the effort and experience. It's extremely concise a true delight to build programs in that are fast, robust and durable. There are a few drawbacks, depending on your perspective: - compilation is slow…

Thanks for your work on falco, it’s a really great library.

Re: Why F#?

#273

Post by [deleted] »

jonsagara wrote: post #103

The killer feature for me is type providers. I need to read a lot of CSV files of varying formats, and the CSV Type Provider lets me make quick work of them in a type-safe manner. https://fsprojects.github.io/FSharp.Data/library/CsvProvider...

[deleted]

Re: Why F#?

#274

Post by throw234234234 »

twodave wrote: post #59

In the case of F#, the use cases are diminishing with every new C# release, since C# is getting better and better at the things F# is supposed to be strong at (record types, pattern-matching, etc.). Better to write the thing in C# using modern features of the more popular and capable language.

Not sure that C# is the more capable language - its still that F# is mostly a superset of C# although C# is catching up. I think they are on par w.r.t capability (i.e. CLR compatible). In terms of conciseness, and expression F# still wins IMO; and given some of the extra features can be more performant at times (e.g code templating/inlining vs just JIT attributes). Custom CE's (Async/TaskSeq), nested recursive seq's great for algorithm dev, DU's, etc. There's a lot of little features C# doesn't have (or don't quite fit) that when I write C# I'm forced to implement still more cruft code around.

IMO its generally more readable as well to non-dev than C# and to dev's outside the Java/C# ecosystem (e.g. Node, Go, etc). I've shown F# code back in the day to non-tech stakeholders and they typically understand it (e.g. data modelling).

Re: Why F#?

#275

Post by throw234234234 »

innocentoldguy wrote: post #148
breadwinner wrote: post #130

Earlier quoted context omitted.

Apache Spark, Delta Lake are written Scala. Being JVM based, it has a large ecosystem. Scala seems like a better choice than F#.

I think Clojure is the better option if you want to do FP using the JVM ecosystem. The problem (for me, anyway) I've run into with Scala is that it supports both functional programming and object-oriented programming. Every code base I've worked on in Scala has ended up being a hodgepodge of both, which I find annoying. However, the best functional programming language is, of course, Elixir. :D

Evaluated F# vs Clojure. Speed of certain algorithms just lacked for me. Value types particularly in tail recursive stacks shines in F# compared to the JVM in general. As usual YMMV

Re: Why F#?

#276

Post by lucyjojo »

michaelcampbell wrote: post #246
innocentoldguy wrote: post #148

Earlier quoted context omitted.

I think Clojure is the better option if you want to do FP using the JVM ecosystem. The problem (for me, anyway) I've run into with Scala is that it supports both functional programming and object-oriented programming. Every code base I've worked on in Scala has ended up being a hodgepodge of both, which I find annoying. However, the best functional programming language is, of course, Elixir. :D

Isn't Clojure similarly (or even moreso) multiparadigm?

i don't think it is. i would say it is functional + bridges to the jvm (which is why it has been ported to many other platforms... there is not that much stuff in the language itself).

it is functional (value) programming first. there are tools to hook in the object jvm stuff but this is not the natural grain of the language.

clojure is pretty much all values and functions (and some macroes).

+ some concurrency stuff

there is no class, there is no inheritance, you don't even have information hiding (no private etc.). you have protocols and multimethods.

(well technically there is private because java but it is not obvious to use and not what you expect, you will very rarely see that in clojure codebases)

honestly it is a nice small yet powerful language, with not too many kludges. my personal coding is either clojure or rust (which has way more kludges, but better than the other stuff in the typed fast compiled world at least for me).

Re: Why F#?

#277

Post by throw234234234 »

shortrounddev2 wrote: post #101
rockyj wrote: post #29

I did try F#, but I was new to .NET ecosystem. For 1 "hello world" I was quite surprised by how many project files and boilerplate was generated by .NET, which put me off. I am all for FP, immutable, and modern languages. But then where are the jobs and which companies care if you write good code? Now everyone wants languages which are easy to use with AI, while reducing workforce and "increased productivity". I have…

I like F#'s syntax when all you're doing is pure logic. But when you have to interface with any IO like a database or REST call or something, you have to abandon the elegance of ML syntax and use these ugly computation blocks. In C# you can do something like this: var post = await _postService.getById(id); in F# the equivalent is basically let getPostById id = async { let! post = blogPostService.getPostById id return…

I find it personally better for CRUD applications than C# and I've written my share in both languages. Your syntax comparisons aren't exactly comparable in the sense that you haven't put in the wrapping/boilerplate around the C# code - you can't just await anywhere. You are also using an async which to run needs to know which context - this can be nice when you don't want to run the composed Task/Async on the current sync context. These days you stick to tasks if you want C# like behavior - and there's libraries to take away some SyncContext overload via custom F# CE's if you want.

The equivalent C# to your F# would be

  task { return! _postService.getById(id) }
Which is somewhat pointless anyway - just return the task from postService directly. There's also no need to run the async synchronously then - Async allow you to run the logic on task, thread, sync over and over - a very different model than tasks.

To make C# comparable to your F# code (tasks are not the same so not quite true) you would need to define a method around it, and find a way if you want to run the resulting Task synchronously to do that safely.

  public async Task GetPostById(id) => await blogPostService.getPostById(id);

  // This is not entirely eq - since tasks are hot
  this.GetPostById(42).Result

Re: Why F#?

#278

Post by jadenPete »

darksaints wrote: post #219

I'm completely convinced that F# (along with Scala, Haskell, and OCaml) adoption has stalled due to having ridiculously bad build systems. More significantly, they are being passed up in favor of Rust, which is a great language but nonetheless a bad fit for a lot of problem domains, simply because Rust has a superior build system. Hell, 80% of the reason I choose Rust over C++ for embedded work is because of the buil…

It’s always puzzled me that so many languages have their own build systems and package managers. Why aren’t programming language-agnostic build systems like Bazel and Buck more popular? It seems so strange that every new programming language essentially has to reinvent the wheel multiple times, inventing a new build system, package manager, formatter, linter, etc. I wonder if we’ll ever see something like LLVM for these technologies.

Re: Why F#?

#279

Post by noahbp »

Lyngbakr wrote: post #258
darksaints wrote: post #219

I'm completely convinced that F# (along with Scala, Haskell, and OCaml) adoption has stalled due to having ridiculously bad build systems. More significantly, they are being passed up in favor of Rust, which is a great language but nonetheless a bad fit for a lot of problem domains, simply because Rust has a superior build system. Hell, 80% of the reason I choose Rust over C++ for embedded work is because of the buil…

While I've never used it in anger, I really quite like dune. Was there something specific that makes you characterise it as "ridiculously bad"?

Not Dune exactly, but having to run 'eval $(opam env)' in the terminal every time you open an OCaml project rather than the default being npm-like, where you can just open the directory and use the package manager command without having to think about it.

Re: Why F#?

#280

Post by Lanayx »

GiorgioG wrote: post #126
aaronmu wrote: post #85

I've been using F# professionally for the past seven years across different contexts. First in a small software shop and now while bootstrapping a SaaS company. Some observations: * It’s easier to attract smart developers to an F# project than to a [mainstream language] project. This was one of my driving beliefs when I introduced F# seven years ago. https://www.paulgraham.com/pypar.html . This is probably just as tr…

As a 20+ year C# dev...where do I learn how to structure apps in F#? In C# my ASP.NET Controller might use a service (or a mediator) to execute some domain logic and that in turn will use a repository pattern (or EF DbContext) to update/query a database. How are dependencies injected in? It seems like there are multiple ways of going about it, but I don't have enough knowledge of F# to know 'the proper way' to do it.

I wrote an article about it. https://medium.com/@lanayx/dependency-injection-in-f-the-mis...
Post reply on HN