Hmm.. I'd argue you need that 'melt-your-fucking-face' experience to truly experience breakthrough. But then again, people react differently to everything
Far from it. Although Dapr borrowed the Actor Framework and Stateful features from Service Fabric, There are a couple of major differences.
a) Stateful services: Your code + data wont' live together on dapr. You would need an additional I/O hop to access cosmos or redis [or your own state provider] to get to the data. In service fabric, once you hit a partition the data lives right there on that node. You will get much lower latency for reliable collection reads with Service Fabric.
b) Service fabric runs classic .net and .net core. Dapr is only for .net core projects. This is a big deal for users who have vast assets on classic .net
c) With external state provider, partitioning becomes a little murky on dapr. Service fabric gives you range and named partitions with replicas. I am not clear how dapr handles replicas or it delegates that to kubernetes or the underlying orchestrator.
d) Service Fabric roadmap: https://github.com/Microsoft/service-fabric#service-fabric-r...
Does that make what the author is trying to convey any more right/wrong? Doesn't matter if you have experience/insight through years of trial or turmoil. If you get to an enlightened state faster, more power to you. Don't discredit the author for missing whatever steps you had in mind