Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Untouched Goldmine of F#

rm4n0s.github.io

Post reply on HN
Print view View original

31–40 of 58 posts

Re: The Untouched Goldmine of F#

#31

Post by SideburnsOfDoom »

breckenedge wrote: post #17
jamalaramala wrote: post #16

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

Yes and no. Would you rather ask for deployment of a microservice owned by a team of 10 people, or a monolith that has changes from a department of 100 people. Which deployment do you think has "extra bureaucracy"? Which one do you think can be done this week?

There are co-ordination costs to microservices. But there are also independence benefits.

Re: The Untouched Goldmine of F#

#32

Post by jcmontx »

cies wrote: post #7
jcmontx wrote: post #3

I really like F#, but I really miss having a full fledged f#-native ORM

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, wit…

Most of the time we do simple CRUD operations, I want this plumbing to be as straight forward as possible. Don't be patronising...

Re: The Untouched Goldmine of F#

#33

Post by lolinder »

jamalaramala wrote: post #16

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

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.

Re: The Untouched Goldmine of F#

#34

Post by thfuran »

jamalaramala wrote: post #28
fluoridation wrote: post #24

Earlier quoted context omitted.

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.

A system can break without crashing. Incorrectly processing financial transactions due to a bug in price calculations would be a good example of a serious breakage that may well be worse than crashing.

Re: The Untouched Goldmine of F#

#36

Post by zbobet2012 »

fluoridation wrote: post #24
jamalaramala wrote: post #16

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

What same-process modularization does _not_ solve is independent lifecycle management. In a monolithic system your change rate often becomes tied to your slowest, most bug prone module or team. If you've some integration test that bakes some piece of important code for 48 hours, you can only make a change _everywhere_ else every 48 hours.

Now sometimes folks (the Windows team famously did this) build systems which identify which tests to run based on changes that occur in the codebase, but that's _not_ easy.

Re: The Untouched Goldmine of F#

#37

Post by mangodrunk »

jamalaramala wrote: post #16

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

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.

Re: The Untouched Goldmine of F#

#38

Post by johnnyjeans »

antigeox wrote: post #23
twic wrote: post #15

Earlier quoted context omitted.

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

the endofunctors operate on the category of you!

Re: The Untouched Goldmine of F#

#39

Post by stonemetal12 »

boxed wrote: post #8

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

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.

Re: The Untouched Goldmine of F#

#40

Post by garganzol »

Another reason why companies moved to microservices is because it is easier to manage smaller projects. Services have stronger boundaries, they can be swapped with newer and alternative implementations, it is possible to combine the power of different technologies.

I came from the other side: I own a huge monolithic web behemoth which is almost unbearable to maintain now. It was built using a now outdated technology, but: it serves customers, it runs the business, it brings profits. Nevertheless, it is a huge pain to even try to change something in it. The project is at its dead end now, it is a one-trick pony who has become too old.

Nowadays I build newer parts using separate well-defined services. It is not textbook microservices, I would call it just services. Imagine building a mini-product that is not publicly available and only used internally. This kind of productized services work well enough to never look back at the fragile monolithic approach.

Post reply on HN