[deleted]
The Untouched Goldmine of F#
21–30 of 58 posts
Re: The Untouched Goldmine of F#
#22> The question is: Why companies moved from monolithic to microservices? What do they try to avoid? One of the main reasons why companies move from monoliths to microservices is to promote ownership and accountability in large codebases. In a monolith where everyone owns the code, developers can break each other's code. With microservices, each team becomes responsible for one part, and (as long as they keep their SL…
Sounds like extra bureaucracy.
It definitely is; but this bureaucracy can be useful when the company has thousands of developers.
Re: The Untouched Goldmine of F#
#23> It may not have the information on the filename or the line of code like the ordinary stack traces, but these are useless information anyway. That is the weirdest and most crazy thing I've read in years.
The whole post feels like it came from a parallel universe. People adopted microservices because stack traces are too long! Exposing the implementation details of a function in its type signature is good! The most meaningful way to specify a function is by how it can fail (this one is fun, though)!
In soviet F# the monads... uh....
Re: The Untouched Goldmine of F#
#24> The question is: Why companies moved from monolithic to microservices? What do they try to avoid? One of the main reasons why companies move from monoliths to microservices is to promote ownership and accountability in large codebases. In a monolith where everyone owns the code, developers can break each other's code. With microservices, each team becomes responsible for one part, and (as long as they keep their SL…
Same-process modularization should solve that problem. Splitting the architecture into separate processes means a crash in one module doesn't propagate to other modules, but the whole system still breaks down if the process is essential.
Re: The Untouched Goldmine of F#
#25> only Odin, F#, OCaml and Zig have [Tagged Unions or Discriminated Unions] The good old missing sum type story. Don't Rust, Haskell, Elm, Kotlin (with sealed classes), etc also have them?
Most languages have them, or allow them to be expressed. The name "Tagged Unions" literally comes from C.
Re: The Untouched Goldmine of F#
#26I upvoted this because I love F#, but I can't say I agree with the conclusions of the author.
Re: The Untouched Goldmine of F#
#27Is TST essentially the validation monad[0]?
Glad to see more folks finding and appreciating FP languages like F#. It's good stuff. Scott Wlachin has a great site to discover more F# goodness[1].
[0]: https://hackage.haskell.org/package/monad-validate-1.3.0.0/d...
Re: The Untouched Goldmine of F#
#28> The question is: Why companies moved from monolithic to microservices? What do they try to avoid? One of the main reasons why companies move from monoliths to microservices is to promote ownership and accountability in large codebases. In a monolith where everyone owns the code, developers can break each other's code. With microservices, each team becomes responsible for one part, and (as long as they keep their SL…
Same-process modularization should solve that problem. Splitting the architecture into separate processes means a crash in one module doesn't propagate to other modules, but the whole system still breaks down if the process is essential.
Not all bugs are crashes. It could be a copy text or price calculation.
Re: The Untouched Goldmine of F#
#29So… if I ever decide I want to change the call stack of a lower level function… I’m going to break types that all my callers and callers’ callers and callers’ callers’ callers’ are depending on? Like, my call stack is enshrined in a type so that to change it means a refactor all the way up to main()?
Re: The Untouched Goldmine of F#
#30> The question is: Why companies moved from monolithic to microservices? What do they try to avoid? One of the main reasons why companies move from monoliths to microservices is to promote ownership and accountability in large codebases. In a monolith where everyone owns the code, developers can break each other's code. With microservices, each team becomes responsible for one part, and (as long as they keep their SL…
> With microservices, each team becomes responsible for one part, and (as long as they keep their SLAs) they can't break each other's code.
When done well, microservices work as a unit of deployment. The team that owns the service code deploys it on their own pace. Sure there is process to follow, but it involves 10 people in that microservice team not 100 people for the monolithic app. This allow for smaller batches and independence of development.