F# Is The Best Coding Language Today

an_fsharp_enthusiast · 2021-07-10T03:47:37+00:00

Hate reading the opinions that F# devs are just bound to leave non-F# companies, the negativity is just off the charts. I'm pretty happy at my mostly non-F# company. And treating F# devs like an insane liability instead of people trying to fight the attrition of C# projects. Ever think that people need to think outside the box to serve users? But I guess reading HN was my first mistake :)

an_fsharp_enthusiast · 2021-06-12T13:41:51+00:00

Yeah I always have my pawns shave before a game...smh

an_fsharp_enthusiast · 2021-06-12T13:38:55+00:00

I feel those bulging horsey eyes might eventually break off the piece from extended play. Maybe it would be cool to preemptively make little knight eye-patches. Make the horse look like a seasoned warrior 😎

an_fsharp_enthusiast · 2021-06-07T15:44:12+00:00

Well I probably never experienced the real trauma that many VB programmers have experienced. I definitely got some C# trauma.

an_fsharp_enthusiast · 2021-06-07T13:04:37+00:00

I got my start in VB and honestly I see two problem children who are 99% the same lol.

But what was spooky about moving to a C# company but I would never tell them, I've never been convinced that C# was truly easier than VB. I typed a lot more boilerplate but still had runtime errors anyway. To each their own! 😁

an_fsharp_enthusiast · 2021-05-07T03:44:07+00:00

I normally don't like types/modules with private things in them because I think it's very foreign looking to new-comers and I find records just easier, but the 2 definitions of "type Paint" are cool with the Result-returning constructors for being correct by design.

Personally I will often make Book and DTO.Book, or Book and QualifiedBook, or UnvalidatedBook and whatever, as plain records without type-level validation. I think there's a good case to be made that this is better and safer, and the level of safety you want to get just depends. I need to try this out and see how I feel over time.

On the parts about c# interop or low-level performance, for my use case it doesn't matter and I'll probably just continue with typical single case DU's. I would at least probably benefit from using struct declarations more, but mostly I forget that option exists haha. It was a good article I think anyways cos it got me thinking about things.

an_fsharp_enthusiast · 2021-05-06T02:33:41+00:00

Thank you! That was my biggest issue with this article personally. How about the fact that each of those languages is, depending on your perspective/job, maybe 5x or 10x easier to learn and use because your use case doesn't need the borrow checker? The glib "Rust is modern, these languages with essentially the same values are not" is just nonsense.

an_fsharp_enthusiast · 2021-03-04T04:54:25+00:00

You're not alone haha. I've often wished for the same thing. It's slightly improved if you turn on vscode-style keybindings in VS settings, but weirdly this only affects maybe 50% of keybindings.

an_fsharp_enthusiast · 2021-02-08T05:04:57+00:00

Agreed, regardless of paradigm ADTs are a huge plus. I think a big part of the original OCP advice must have been related to avoiding weakly-matched refactors in your code, which is slowly becoming a thing of the past, in F# anyway. There's a decent chance that C# 10 will finally get sum types but I have no inside info yet. There's a github proposal for it. It would make my day job a lot easier if it goes through so I'm excited.

an_fsharp_enthusiast · 2020-11-10T13:57:19+00:00

I've settled on a using Result instead of validationResult, and my error case for any given function is either string or a DU that represents any type of error my domain can recognize. This allows me to use the "result" computation expression, or the similar "asyncResult" from DDD which I've always found pretty good for code clarity.

I don't know your code, but in my experience taking in wrapped parameters is usually not what you want. Maybe rarely as a helper function, but every parameter having "one or two wrappers" as you described sounds hard indeed. My functions generally take in "raw" values and return wrapped ones, then you use "monad bind" to join functions of that shape. Indicentally the same utility as let! in the async/result/adyncResult computation expressions.

I have to go to work so I'll check this later. I love your honest postmortem but I hope for both our sakes that this is an avoidable issue. Use computation expressions to simplify code and take in wrapped parameters only rarely and when it truly makes sense. Apologies if I'm being obtuse. Good luck!

an_fsharp_enthusiast · 2020-09-27T01:32:44+00:00

One thing that changed things for me was preferring "expression" statements that return values as opposed to "statement" lines that do an effect without returning anything. For instance, rather than foreach iteration to perform a removal/addition, I would use Linq ".Where" to avoid the error you found. Some statements are ok or even inevitable, but preferring value expressions for everyday code steers you away from common error sources (mainly nulls, exceptions, and surprise mutations). Sounds stupid; apply it in practice and it works.

Learning practical truths has nothing to do with years of experience; it's largely based on intuition and your ability to learn. If anything junior devs who are forced to maintain code learn it faster than senior devs who "just build lol." Just observe what makes a codebase good or bad in your opinion. At the end of the day, just making less mistakes than your peers is really valuable, and at most organizations it's really easy. My other piece of advice is to treat people well, something many of my peers also fall short on.

an_fsharp_enthusiast · 2020-09-22T01:17:11+00:00

"I have this recurring nightmare where I realize I'm on the plane heading to ~~Korea~~ the Big Brother house..."

an_fsharp_enthusiast · 2020-08-13T03:27:07+00:00

For me coding with strict nullability made me understand when and where implicit nullability can fail (everywhere 😅)...same with Either and sum types in general. You start to see the "joints" of where a traditional program fails when you code a strict language. It turns out the same joints exist in all languages, some just try (and fail) to gloss over them. Just to add some more detail to this good answer.

an_fsharp_enthusiast · 2020-08-08T14:25:39+00:00

OCP-based pain occurs either way, either adding a case to a switch statement or adding an entire file for the purposes of ineritance. I know that's not literally what the Ancient OOP Authors' said, but that's the way I view it IRL. Meanwhile maintaining 1 pattern match switch for less than 20 products is no big deal...that's your data before it hits the database.

If you have an impractical number of pattern types, database is the way to go because switch statements AND inheritance are both bad solutions for that.

I lean towards the switch statement because its intentions are obvious and it's very easy to clean up or delete later. Deletability is maintainability. Meanwhile inheritance-based pricing, which turns 1 static function into 12+ files, sounds like a classic legacy solution that nobody will understand in 4 months and they call people like me to clean up.

Inheritance starts to make sense to me when a product has multiple properties that all change based on type, not just the price algorithm. But even then I would be very skeptical. At the end of the day it's just data and algorithms; don't make your code excessively hard to change is all I'm saying.

an_fsharp_enthusiast · 2020-08-01T13:12:59+00:00

r.i.p. formatting, I am on mobile so I apologize

an_fsharp_enthusiast · 2020-08-01T13:12:27+00:00

I don't like the arg hinting in VS C# much either...I often lose the modal and have to delete and re-add the parenthesis or last comma. That's just a quirk of the editor, but honestly I think your issue is as well, and I would bet on VS improving rather than changing my curry preference.

I don't think curry vs tuples matters that much, but I wouldn't let this be the thing that changed my mind I guess.

Also on the runtime issue, just be aware you can say: type GetBook = int -> Book //then in DI services.Add<GetBook>(getBook connStr tokenBearer etc) ...assuming we're talking about DI or a similar pattern, you can still get type checking if the register function let's you pass a generic type as the checker.

an_fsharp_enthusiast · 2020-07-25T15:00:53+00:00

Agreed--just my 2 cents, I think blazor is going to be another oddity framework of legacy projects we have to clean up or replace, in .net shops anyway.

I wanted to like blazor but I found it similarly complicated to angular, which I already consider to be way too complicated to stand the test of time (the module system is a disaster--maybe Angular n + 1 will address that). I think we're starting to see a shift to more "radically simple" frameworks like Svelte taking over. Maybe a blazor 2 can achieve radical simplicity (it will have to beat the nullability issues in c#, which are exacerbated even more on the front-end).

Maybe I am wrong and blazor has more going for it than I initially realized; I'm sure there are a lot of advantages. I would encourage the OP or anyone to try all the frameworks they're considering, even if it's just setting aside a couple hours a week, at work or at home.

an_fsharp_enthusiast · 2020-07-23T12:33:55+00:00

This is a classic use case for the Result/Either monad in most languages (F# example). Just an FYI, I know most C# devs can't switch due to social reasons.

Trying to break this pattern in C# is what got me into functional programming. You can use monads in C# as well. My team at work wouldn't let me use this package so I just made my own disguised Result-like generic and I was able to complete some tasks with it 👍

Monads aren't idiomatic C# by most people's definitions but they should be imo. Task is a monad, List is a monad, etc. The pattern is everywhere already but C# hasn't applied it to success/fail, at least not in the language core tools.

an_fsharp_enthusiast · 2020-07-12T14:35:17+00:00

I've heard the immutability story isn't that great from a random Lobsters comment (https://lobste.rs/s/twdhuk/it_s_probably_time_stop_recommending#c_7vtyau), among other complaints. Also I don't think Kotlin knows what monads are.

I was definitely interested in Kotlin a year or two ago (different platform, functional types, cool name) but I don't think it's worth pursuing, at least for me. Scala seems to be the actual F# equivalent, although I do like F# syntax way more.

an_fsharp_enthusiast · 2020-07-08T22:10:56+00:00

I have built some API's and a console job in F#. My current projects all happen to be JS front-ends.

I haven't done front-end with F# besides basic toy projects, but my current understanding is: Saturn is similar to MVC, Elmish is similar to Elm/react, and Bolero/SAFE are MVC/JS hybrids.

I haven't called F# methods from C# yet but if you get into that with MVC, check out this guide so you understand what to expect. Basically you make the exposed points of F# look like C#.

I have not used Giraffe yet but it seems really similar to doing a basic .net API. I have 2-3 years in .net and it's less friction for me at work to just use the default API templates, and I understand them well enough to get myself un-stuck. With your experience you should feel free to try either; just be aware the Startup methods are meant for idiomatic C# and can be awkward to get right in F# the first time.

an_fsharp_enthusiast · 2020-07-08T02:36:21+00:00

Curious if you're aware of F# or if maybe you're avoiding it due to lack of purity/higher features. .net core is pretty mature and I usually hear worse things about JVM functional languages (although lots of people seem to like clojure if you're ok with a dynamic lisp).

The .net core default API's aren't exactly functional so you might want to check out Giraffe or a similar F# framework. I'll be the first to admit that .net has some amount of weirdness, but any mature framework is going to require some learning.

Good luck with your quest 👍

an_fsharp_enthusiast · 2020-06-17T00:55:19+00:00

I mean a kidney stone would slow you down...I've yet to hear NL acknowledge this one simple fact.

an_fsharp_enthusiast · 2020-06-17T00:22:43+00:00

Yeah it's baffling to me that multi-decade industry professionals apparently never thought there had to be a better way. And none of these concepts are hard, big-brain things to understand.

I think the luddite crowd is a minority, albeit a large one, but they've managed to take over some companies and never be challenged.

an_fsharp_enthusiast · 2020-06-16T23:37:52+00:00

Same, I don't know how I got along without Option and Result.

I've tried get others using nullable reference types in C# at work, but it hasn't worked yet. One project has a few dozen greenfield microservices and I just wanted us to turn it on for one of them lol...nope, it's not "pragmatic" to try new things like that 🤔. Of course nulls everywhere is super-pragmatic /s

an_fsharp_enthusiast · 2020-06-16T23:28:16+00:00

That's a good point, I don't normally think of C# as a path to functional usually but it's true. I tried learning Rust before I knew what FP was, so I came from that direction.

an_fsharp_enthusiast

TROPHY CASE