Thanks Phillip, much appreciated! We are approaching 100K LOC in the project and I have to say we are pretty happy. We have moved beyond the initial sync approach and working on async calls wherever we can. The code got a lot cleaner in the last while too. We have started to use ROP and created a way of bubbling up errors from low level infra code to user facing functions. We have also created a few Lambda function, some of them is calling other functions to fetch data. It works very well.
Very cool! 100k LoC is quite a lot. I'm glad you're having a great time. Is there anything in F# or F# tooling you feel is missing that you'd love to use?
Yeah I should clarify that we have everything in that 100K LOC, devops, frontend (Elm) and many-many backend systems (F#). The actual breakdown I am not even sure about.
Few things about F#:
the foundation of the language is rock solid (no nulls, discriminated unions, type params, etc.) We use currying a lot makes some things like logging or shortening a function with many parameters easy.
libraries are (mostly) amazing, some gotchas with interop with async C# and nested exceptions coming from C# libraries
working with async was not an easy start, 90% of documentation is about hello world example with printf which is not something that you do a lot (at least not us). Documentation should be just: "use this until you understand in depth what you are doing" I know this is a slippery slope but it is funny how this link gave us more than all the other documentation combined:
traceability is a bit hard, even though there are great tools like dotnet trace and speedscope (even though there is no out of the box support for, start this application and trace everything it does (you have to work with ./bin... & echo $!)
traceability in a cloud / lambda / serverless environment, we had some hoops because of the lack of example how to operate in these environments effectively
not really a tooling issue but ROP (Railway Oriented Programming) is really neat and it would be great to see more about it or implement the functions used in ROP a lot (Option.map, Option.bind, etc.) for other types which we currently do ourselves.
I personally use dotnet fsi a lot, it is a bit unfortunate that it does not have history by default (maybe there is already some project addressing it)
These are my thoughts, my co-worker chime in, he has additional points I am sure. :) So far I would say this was the best decision to get into F# that I have made in the last 5 years. We are happy with the performance we got and how solid our system is, even though we are dealing with horrific inputs (broken CSV files, emails, etc.) that are traditionally hard to deal with. Since we introduced ROP the code based became super simple with no visible branching and it is very simple to express complex computations, that can be read and modified by juniors with ease.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks Phillip, much appreciated! We are approaching 100K LOC in the project and I have to say we are pretty happy. We have moved beyond the initial sync approach and working on async calls wherever we can. The code got a lot cleaner in the last while too. We have started to use ROP and created a way of bubbling up errors from low level infra code to user facing functions. We have also created a few Lambda function, some of them is calling other functions to fetch data. It works very well.
Very cool! 100k LoC is quite a lot. I'm glad you're having a great time. Is there anything in F# or F# tooling you feel is missing that you'd love to use?
Yeah I should clarify that we have everything in that 100K LOC, devops, frontend (Elm) and many-many backend systems (F#). The actual breakdown I am not even sure about.
Few things about F#:
the foundation of the language is rock solid (no nulls, discriminated unions, type params, etc.) We use currying a lot makes some things like logging or shortening a function with many parameters easy.
libraries are (mostly) amazing, some gotchas with interop with async C# and nested exceptions coming from C# libraries
working with async was not an easy start, 90% of documentation is about hello world example with printf which is not something that you do a lot (at least not us). Documentation should be just: "use this until you understand in depth what you are doing" I know this is a slippery slope but it is funny how this link gave us more than all the other documentation combined:
fssnip.net/hx/title/AsyncAwaitTask...
traceability is a bit hard, even though there are great tools like dotnet trace and speedscope (even though there is no out of the box support for, start this application and trace everything it does (you have to work with ./bin... & echo $!)
traceability in a cloud / lambda / serverless environment, we had some hoops because of the lack of example how to operate in these environments effectively
not really a tooling issue but ROP (Railway Oriented Programming) is really neat and it would be great to see more about it or implement the functions used in ROP a lot (Option.map, Option.bind, etc.) for other types which we currently do ourselves.
I personally use dotnet fsi a lot, it is a bit unfortunate that it does not have history by default (maybe there is already some project addressing it)
These are my thoughts, my co-worker chime in, he has additional points I am sure. :) So far I would say this was the best decision to get into F# that I have made in the last 5 years. We are happy with the performance we got and how solid our system is, even though we are dealing with horrific inputs (broken CSV files, emails, etc.) that are traditionally hard to deal with. Since we introduced ROP the code based became super simple with no visible branching and it is very simple to express complex computations, that can be read and modified by juniors with ease.