24
AleCx04
10d

I wrote a prototype for a program to do some basic data cleaning tasks in Go. The idea is to just distribute the files with the executable on our shared network to our team (since it is small enough, no github bullshit needed for this) and they can go from there.

Felt experimental, so I decided to try out F# since I have always been interested with it and for some reason Microsoft adopted it into their core net framework.

I shit you not, from 185 lines of Go code, separated into proper modules etc not to mention the additional packages I downloaded (simple things for CSV reading bla bla)

To fucking 30 lines of F# that could probably be condensed more if I knew how to do PROPER functional programming. The actual code is very much procedural with very basic functional composition, so it could probably be even less, just more "dense"

I am amazed really. I do not like that namespace pollution happens all over F# since importing System.IO gives you a bunch of shit that you wouldn't know where it is coming from unless you fuck enough with Ionide and the docs. But man.....

No need for dotnet run to test this bitch, just highlight it on the IDE, alt enter and WHAM you have the repl in front of you, incremental quasi like Lisp changes on the code can be REPL changed this way, plethora of .NET BCL wonders in it, and a single point of documentation as long as you stay in standard .net

I am amazed and in love, plus finding what I wanted to do was a fucking cakewalk.

Downside: I work in a place in which Python is seen as magic and PHP, VB.NEt and C# is the end all be all of languages. If me goes away or dies there will be no one else in this side of the state to fuck with F#

This language needs to be studied more. Shit can be so compact, but I do feel that one needs to really know enough of functional programming to be good at it. It is really not a pure language like Haskell (then again, haskell is the only "mainstream" pure functional language ain't it not?) but still, shit is really nice and I really dig what Microhard is doing in terms of the .net framework.

Will provide later findings. My entire team is on the Microsoft space, we do have Linux servers, but porting the code to generate the necessary executables for those servers if needed should be a walk in the park. I am just really intrigued by how many lines of code I was able to cut down from the Go application.

Please note that this could also mean that I am a shit Golang dev, but the cut down of nil err checkings do come somewhere.

Comments
  • 9
    There's someone I want to tag but I forgot how many 1's and 0's he has in his name and in what order. Binary boi, if you can see this, I think you and Alex are gonna get along well.
  • 8
    @rutee07 tee hee

    But yeah, that’s pretty much what I’ve been trying to tell people who go wtf is F# y would I want to?

    Glad someone’s found the path to light! (P.S. my workplace is pretty similar… so no F# for prod here - but proof of concepts and experiments, hell yeah!)
  • 4
    I didn't find a fast answer by googling it: does f# compiles into a single executable binary without library dependencies to the os?
  • 4
    @bosi possible, yet not default behavior, if I remember correctly from the top of my head. It’s been some time when I’ve last had the chance to touch any F#
  • 3
    F# or as i like to call it, ocaml
  • 2
    @100110111 it is not that important. I just wanted to point out that I think it's might not be a good idea to compare 2 languages which are not comparable.
    F# has less loc? Sure, starting at the fact that indenting is used instead of brackets for code structure.
    You don't like that go has no exception handling and does everything with if err!=nil checks? That's ok because handling of errors is different and golang supports multiple return values and beliefs that each function should be aware of errors which might occur.

    Its always a thing of the use case you have. There are cases where F# is better than golang and there are cases where it is vise versa.
  • 2
    @bosi Yessir, a standalone executable is possible through (at least as I know in .NET Core, don't quote me on how it worked before) using the --standalone flag either through the CLI or through the Visual Studio IDE.

    I have, however, not tried it yet since the tool lives right now as proof of concept in my work machine.
  • 2
    @100110111 It really is a nice language. Looks super clean,a although I will say, functional programming languages always strike me as dense in that a few lines might have a looot of things happening in the back. For this I can say that Go just exposes everything. Ups and downs, but for right now I want these two to replace a couple of other things I have in Python etc. Lets see!
  • 3
    @bosi I agree, for the record I really do love Go and don't mind the overpopulation of error checking, if anything I welcome it. There are many things inside of each language that are good. Go makes me really conscious of the things that I put in a program and I like how the code is structured.

    It really all depends on the use case.
  • 1
    @yellow-dog indeed Ocaml .NET
Add Comment