The Untouched Goldmine of F#

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.

> 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.

Well, they still can and do break someone else's code. It is just breaking someones code with more steps in between. And who is at fault isn't necessarily as clear cut.

Yes. And the little-understood reason why microservices became the answer is that the tools for defining clear ownership boundaries in a single service were (and to an extent still are) lacking.

Defining a clear public contract in most existing programming languages that cannot be violated by a lazy programmer is tricky. Java's package-private should be the answer but is too blunt and ends up requiring a team to make things public so they can use them. C# has a bit more control that might make clear contracts possible (I haven't tried), but not everyone wants to use it because Microsoft. And most of the popular languages at the time of the rise of microservices had basically no mechanism for defining public versus private interfaces.

Microservices allow you to do that in any language— your HTTP API is your public interface. Anything inside of that is physically impossible to access without adding an explicit build-time dependency, which would be trivial to catch in code review.

Yes, code review could theoretically solve the same problems, but in practice no organization is that disciplined. You need tooling, and those tools didn't exist yet when microservices came to be. We're seeing them develop now (Rust's visibility modifiers are very powerful, and monorepo tools are starting to develop lints that can impose module boundaries on languages that lack them natively), and it's not a coincidence that around the same time we're seeing a lot of people moving back to monoliths.

Sounds like extra bureaucracy.

Having micro services doesn’t protect against affecting another team’s code/service. Think of a service changing some behavior or contract on either side of your service. Are you thinking of a person changing the actual code of another team? That can be solved without micro services.

Yet some companies use monorepos, so everybody has access to everything.

> 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.

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)!

No doubt it’s harder to write structured code and assertions against a string stacktrace, but as a human reading it, the information is immensely valuable.

Depends on how your app is structured, but it very well can be.

badvalue = dobadthing(); dostuffwith(badvalue);

Depending on the indirection between dobadthing() and the place that chokes on badvalue the stack trace can be completely worthless. It is one of the reasons people hated the original Spring. Claimed it decoupled stuff but all it really did was obfuscate.

I have seen similar claims made about Clojure. Bad data coming from somewhere, but no way to trace it through the system. Sure you can filter bad data in to the garbage can, but that just masks the issue not fix it.

Yeah, that's also my main problem with the article. Otherwise great to prmote TSTs.

I think the TSTs should also contain the stacktrace. Not or X or Y, but both X and Y.

It seems a step on the path to learning both the Either Monad and the Validation Monad, especially for someone coming from golang which desperately needs a proper Either Monad and essentially has baked in the worst of both imperative and FP worlds in the way everything returns as if there were an Either Monad but not enough useful combinators nor a semblance of do-notation/Computation Expressions exist.

Which is fun to see, really, because it is interesting watching someone rediscover FP principles from first practice.

I dont think so, TST and stacktraces are different.

Stacktraces show me call-stack to the point the error happened. Something TST does not always show: different call-stacks can result in the same (or very similar) TST-stacks.

It is possible to return the stacktrace as part of the TST error (not just an error message but also a stacktrace).

I got to this part of the article and concluded it wasn’t worth my time, nor probably anyone else’s

1. Absurd claim that file names aren’t important in a stack trace 2. Claims they’re sharing a feature of F# that is never used, then later reveals they’ve been studying F# for 3 months 3. Then this statement about tagged unions

Most languages have them, or allow them to be expressed. The name "Tagged Unions" literally comes from C.

No you dont. Sorry for the blunt answer.

ORMs are a bad idea, even when using OO langs: they make the simple queries slightly simpler (`Users.getById(id: Long)`), they do not help you for hard queries (ORM-using codebases of size usually have hard-SQL-queries "in strings").

Most users of FP langs know this and hence will not even try to implement ORMs.

Look into jOOQ, LINQ-method-syntax (or whatever it is called, without the funny SQLish syntactic sugar), SQLDelight or sqlx for non-ORM options that improve embedding SQL in general purpose langs.