Advise a browse through "Domain Modeling Made Functional by Scott Wlaschin" https://www.amazon.co.uk/gp/product/1680502549
takes these ideas further. (it is f# for the most part but many of the ideas can be implemented in other (non functional) languages)
fsharpforfunandprofit's author wrote an excellent book:
Here's his NDC talk: https://www.youtube.com/watch?v=Up7LcbGZFuo
Here's his rather influential "railway oriented programming" talk: https://vimeo.com/113707214
Pluralsight has several courses on F# if you search for "fsharp", including ones on unit testing, TDD, type driven development, and functional architecture, all by Mark Seeman. I agree with you - he's an excellent speaker/teacher!
> I just want to rewrite some Go services that use Postgres and ports/adapters pattern in F#, throw them on k8s and compare the results to learn more about the practical benefits of this paradigm for boring apps.
NGL, I feel like this is the wrong way to approach this. If you're just building a CRUD app, then there are a billion and one libraries/frameworks/languages that do this just fine. I'm sure Go has 'em, and you shouldn't introduce the additional complexity of a new language/runtime to your team.
Where F# shines is when there's intrinsic, essential complexity in the domain. Even something as simple as "user input validation" may count as domain complexity. For example in my domain, I have a DU who's cases are "IdempotentError" and UserInputError * string
. In the case of an IdempotentError, I just report things are groovy back to the user and throw away the error. For a UserInputError
, I display the associated string. That string may/should be a type if you're starting to do internationalization. Note how the complexity increases...
re: Postgres I would be careful adopting fancy stuff like a postgres type providers. They work well for the dev environment but require a bit more TLC to work with a CICD and a production system whose schema is constantly migrating. Dapper may work better for your situation, at least until you get the hang of F#: https://isthisit.nz/posts/2019/sqlite-database-with-dapper-and-fsharp/
Yes you are right, this is dense for several reasons.
If the reader is not familiar with the functional programming such as ADTs, records, monads. That is already an obstacle.I would recommend to read these books in this order and come back to the repository.
Lets say, in two months, the repository will have more comments in the modules with detailed explanation about the tools in Idris and about the ideas. At that time the READMAP.md should be complete. I still have to linearize the content and write many comments and documentation, that will help with the understanding. My goal there is to create a nice tutorial on Idris, and show easy use-cases of dependent types.
I didn't implement the simplest solution for the material from Scott's DMF book, if my goal would have been that I am not sure, if I used dependent types. My goal was to turn all the implicit knowledge from the DMF book into explicit knowledge and code with the help of the dependent types. I am looking for the answer for the real question; how to create maintanable architecture. As the result of this experiment; we have a function which computes an HTTP Request to HTTP Response function from the high level overview of the bounded context.
If somebody is already familiar with FP and monadic programming there are new approaches to monadic programming too. The DMF book gave a really good domain, for which a Free-Monadic DSL arose, and because Idris is multi-backend compiler the DSL approach fits well to define different implementations for the DSL which could run on different platforms. There are some applied dependent types around state machine mapping to executable semantics, around the type safe SQL representation, etc.
I am experimenting with Dependently Typed Software Development. I don't say this is the only way one should write software in Idris and Dependently Typed approach, rather than this repository contains some gems, and I will bring them to the surface over time with good documentation and examples. Dependently Typed Software Development is something new and we have to experiment with it. Everyone who looks into this repository should look at it as a new lingo, new patterns in software development to answer the old questions; how to write something which is maintanable, how to prevent future bugs, how to prevent regression. Although at the first sight it seems complex, but which software is not complex that is placed in production.
Does that answer your question?