Fibers are an abstraction over sequential computation, similar to threads but at a higher level. There are two ways to think about this model: by example, and abstractly from first principles. We'll start with the example.
(credit here is very much due to Fabio Labella, who's incredible Scala World talk describes these ideas far better than I can)
Consider the following three functions
So the hacker news post said my comment was too long. Warning, long, opinionated post:
Scala dev for 10+ years here. Spark is weird. Databricks has a style guide that deliberately chooses not to use scala features that the rest of the community uses, and doesn't follow the same best practices around library and scala major version usage that the rest of the community uses [1]. It's no surprise that the project has trouble interoperating with libraries outside of the spark ecosystem, and is therefore a maintenance problem.
Spark's style and compatibility problems
Scala isn't a maintenance nightmare, but it does attract a lot of newcomers who dive in, don't stick within one of its many ecosystems, get confused, and generally leave a mess, and that is a direct result of the fact that scala is a multi-paradigm, relatively expressive language to the one(s) it is competing with and pulling developers from, and that those developers, for the large part, don't really want to change and think that Scala is just a
Why you prefer cats instead of zio? TF? It’s looks like zio ecosystem more widely and zio 2.0 has better performance What do you think?
Great question!
Performance-wise, it really depends on what you're doing. The problem with benchmarks (including the ones posted for ZIO and Cats Effect) is that they apply only to abstract situations, which are often nothing like what you see in real applications. A great write-up on this problem by Daniel Spiewak here, he wrote it better than I ever could: https://gist.github.com/djspiewak/f4cfc08e0827088f17032e0e9099d292
Also, this is not an app meant for production - I don't care that much about performance under load because there will be no load. And individual operations will often be bounded by I/O anyway, so the efficiency of the underlying runtime is likely not going to make a noticeable difference in use. Then again, both the client and server are JVM apps, so even the start-up penalty of the client will slow us down than picking even the least efficient e
| Classes | |
| * Keith Devlin - Introduction to Mathematical Thinking - https://www.coursera.org/learn/mathematical-thinking | |
| * Michael Genesereth - Introduction to Logic - https://www.coursera.org/learn/logic-introduction | |
| * Robert Harper - Homotopy Type Theory - http://www.cs.cmu.edu/~rwh/courses/hott/ | |
| Books and Articles | |
| * Benjamin C. Pierce - Types and Programming Languages - https://www.cis.upenn.edu/~bcpierce/tapl/ | |
| * x775 - Introduction to Datalog - https://x775.net/2019/03/18/Introduction-to-Datalog.html | |
| * Bartosz Milewski - Category Theory For Programmers - https://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface/ | |
| * Benjamin C. Pierce et al. - Software Foundations - https://softwarefoundations.cis.upenn.edu/ |
Think of all the arguments you've heard as to why static typing is desirable — every single one of those arguments applies equally well to using types to represent error conditions.
An odd thing I’ve observed about the Scala community is how many of its members believe that a) a language with a sophisticated static type system is very valuable; and b) that using types for error handling is basically a waste of time. If static types are useful—and if you like Scala, presumably you think they are—then using them to represent error conditions is also useful.
Here's a little secret of functional programming: errors aren't some special thing that operate under a different set of rules to everything else. Yes, there are a set of common patterns we group under the loose heading "error handling", but fundamentally we're just dealing with more values. Values that can have types associated with them. There's absolutely no reason why the benefits of static ty
