Hacker News new | past | comments | ask | show | jobs | submit login
Cellular Automata in F# (isthisit.nz)
94 points by de_keyboard on Nov 6, 2021 | hide | past | favorite | 15 comments



F# is a pretty cool language. What do you think about coding in it compared to other languages? (And what other?) Would love to hear some comparisons.


Since getting into F# as a hobbyist, it's put me off doing C# professionally. Makes doing C# for typical business dev seem like walking through treacle.

There can be a lot to learn, which is a mix of functional programming stuff (recursion-first, immutability, and getting used to type definitions and function signatures), and F#-specifics like computation expressions, active patterns and quotations.

There will be many better examples than mine, but here's some more F# cellular automata stuff from last year's Advent of Code (spoiler alert): https://github.com/lukesdm/aoc-2020/blob/main/FSharp/Day24.f...


When writing C# after learning F#, I’m constantly thinking to myself that I could make this or that data relationship explicit and verified by the compiler if this were F#, but it’s C# so instead I have to leave the relationship implicit and hope that future maintainers are able to piece the relationship together.


F# really is the most "production" a general-purpose functional language is right now, IMO. Languages like Elm have really hit their niche but you can't, say, write a CLI util in Elm (maybe you can by now, but it's definitely not the intended usecase). I like it quite a bit, and if you're a Java/.NET programmer you should really check it out if only to learn about FP principles. But, in no particular order, here's a few things about it that I just don't like:

1. F# is pretty clearly a second-class citizen on the CLR compared to C#, and IMO this really hamstrings the biggest advantage of F#, i.e. access to the CLR. For example, until F# 6.0 F# had its own Async primitives while C# had its own, and you can guess which one most CLR libraries tended to use.

2. Some of OCaml's more advanced type features didn't make it to F#, notably functors - and as a result writing generic code involves writing classes and interfaces and not functors or typeclasses. I really don't like this bit of F#, and I wish it had a more FP way for writing generic code. If you want a much more elegant FP experience, OCaml is significantly better.

3. The community is small, not as small as, say, OCaml's, but IMO if you want a thriving community for a hosted FP language Scala is more interesting. But Scala is much more "multi-paradigm" and OO than I like, so I prefer F#.


> F# really is the most "production" a general-purpose functional language is right now, IMO

You're kidding, right? Cisco (and juniper?) Switches run erlang on the control plane, as does freaking Whatsapp and the British NHS; discord, divvy, brex, pagerduty, slab, PepsiCo, Boston MTA, and stripe use elixir to varying degrees, not to mention tons of companies you haven't heard of.


Erlang is functional too but I think OP meant in the ML family.


F#'s async primitives are much more ergonomic than `Task` though. For example, cancellation is trivial to control with very little boilerplate, whereas `Task` requires boilerplate all over the place.


I use it as a hobbyist, it's much more pleasant to program in than C# once you get over the minimal hump of thinking more functionally than you would in C#/Java/etc. It has a great type system and the available tooling is pretty nice (powerful tools for data, parsing, etc exist for it as with many other functional or math-oriented languages). The annoying bit is that MS doesn't seem to care that much about it despite it being much sleeker, flexible, and terse than C# or VB, and thus it tends to sit unused despite all its niceties.


I don't know F#, but from what I gather it's very similar to OCaml which I do. To put it bluntly, after OCaml, most other languages feel ugly. OCaml is my idea of what programming should be: graceful, ordered, well-designed, mathematical, yet practically applicable to real-world problems.


F# has a few significant differences vs. OCaml, but for the most part it makes up for it by having a wider ecosystem you can tap into. I also started out with OCaml (and also had the same "this is what programming should be like" reaction that completely broke any other language to me ;_;), but just the ecosystem around F# has made me ignore some of its .NET warts to get shit done. For example, you can build cross platform apps with Fabulous, a pretty high performance web server with Giraffe, and the web app with Fable and React. Worth checking out if you wanted to build something in OCaml but didn't have the right libraries to focus on your problem instead of reinventing the wheel.


It is a great language for ML fans, probably one of the best ML descendants in regards to tooling.

However it has always been a kind of black swan on Microsoft's .NET strategy and Visual Studio tooling.

The best way to use it, while being able to enjoy all the tooling on the .NET ecosystem, is to mainly focuses on using F# to write libraries, with the UI written in C#/VB.


I've used it a lot as a hobbyist and a little at work (about ~5% of our production code is F#). I really like it but I use it differently that a lot of F# people do, in that I am less interested in the functional aspects of it and more in some of the other fascinating features is has (like type providers, active patterns, sum types etc).

It shares heritage with OCaml and Rust. I sometimes like to call F# "Rust with garbage collection".


Sometimes I tell people that F# is “easy-mode Rust” :)


Sum types and exhaustive pattern matching are functional features though.


Yes, out of the soup of functional features I very much like sum types and everything being an expression. Feels missing when you move to something with that.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: