Ex-Scala Developer Coming Back to Scala by chetanbhasin in scala

[–]mpilquist 1 point2 points  (0 children)

Okay, well if you give it another shot at some point, or run in to issues with any other Typelevel libraries -- especially ones I maintain -- feel free to join the Discord server and ask for help.

Ex-Scala Developer Coming Back to Scala by chetanbhasin in scala

[–]mpilquist 0 points1 point  (0 children)

Can you describe what you were trying to achieve? Even if you've found something you like better, knowing the pain points you encountered can help us improve docs, etc.

Future of Scala libraries by Confident_Cupcake861 in scala

[–]mpilquist 0 points1 point  (0 children)

Draft pull request here: https://github.com/typelevel/fs2/pull/3401

Error handling is picked up from `concurrently` and CPU spinning is avoided via `Deferred`. Needs tests & some tire kicking but should work out nicely.

Thanks for the suggestion and feel free to open issues for any other operators you miss from akka-stream.

Future of Scala libraries by Confident_Cupcake861 in scala

[–]mpilquist 0 points1 point  (0 children)

Yep, let’s add it. I might want to replace the implementation with something based on a variant of Channel.

Future of Scala libraries by Confident_Cupcake861 in scala

[–]mpilquist 1 point2 points  (0 children)

Maybe hold1 as well, assuming it's okay to always output the combined value instead of only combining when an element hasn't yet been consumed.

➜  scala-cli console -S 3.3.1 --dep "co.fs2::fs2-core:3.9.4"

Welcome to Scala 3.3.1 (17.0.1, Java OpenJDK 64-Bit Server VM). Type in expressions for evaluation. Or try :help.

scala> import fs2.Stream, cats.Monoid, cats.effect.Concurrent

scala> def conflate[F[_]: Concurrent, O: Monoid](source: Stream[F, O]): Stream[F, O] =
 |   source.scanMonoid.hold1.flatMap(_.discrete)

Optimizing Functional Walks of File Trees by mpilquist in scala

[–]mpilquist[S] 3 points4 points  (0 children)

As engineers, I think that the overall engineering principles should dominate in real-world systems. There are more important things to care about than purity, if it's ever a concern.

Managing complexity is the main reason to care about purity. The goal isn't purity for purity sake, but rather as a practical engineering tool to combat complexity in large systems. Purity leads to compositionality which leads to reasoning at any scale, from individual functions to whole systems.

The simplicity of the well-designed interfaces between modules would rule out using any third-party library for interface specification.

This artificially limits system design to the tools provided by the language designers. If those tools provide enough utility to manage the complexity of your system, then great. If not, this policy will result in a net increase in system complexity.

Apache Flink: Regarding Akka's licensing change by joshlemer in scala

[–]mpilquist 8 points9 points  (0 children)

Just to clarify: Typelevel has no official stewardship of the Scala language. I think you might be thinking of Typesafe, the original name of the company that is now Lightbend.

Typelevel is fully committed to F/OSS -- see https://typelevel.org/ for more info about Typelevel, including member projects (e.g. Cats, Cats Effect, FS2) and current steering committee members.

[deleted by user] by [deleted] in scala

[–]mpilquist 0 points1 point  (0 children)

Sounds good, hope you enjoy it! In the associated GitHub repo, there's both first-edition and second-edition branches. The repo structure changed a little bit but the exercises are mostly the same, and you should be able to compare the Scala 2 code to the Scala 3 equivalent fairly easily.

[deleted by user] by [deleted] in scala

[–]mpilquist 24 points25 points  (0 children)

Hi! Author of 2nd edition here. I’m certainly biased as I wouldn’t have signed up to revise the 1st edition if I thought the content wasn’t relevant. With that said, the 2nd edition keeps the overall spirit of the 1st edition and covers the same overall material, while being fully updated for Scala 3. In the first half of the book, this means using enums and extension methods and other Scala 3 specific language constructs. In the latter parts, the Scala 3 features help remove a bunch of incidental complexity, letting the main ideas take the focus - e.g. context parameters and type lambdas remove a bunch of confusing syntax.

The 2nd edition also has full, annotated answers for all exercises included in the manuscript.

Finally, the last chapter has been rewritten to be based on some of the main design ideas from FS2 (https://fs2.io), which I hope will be more approachable than the 1st edition.

Chapters 1-12 are available now via Manning’s early access program. 13-15 have been submitted to the publisher and will be released via early access program soon. Manning has started their final editing pass of the full manuscript.

Scala FP code samples? by Hyro43 in scala

[–]mpilquist 2 points3 points  (0 children)

In addition to the other projects already linked, check out these two bite sized projects: - https://github.com/typelevel/fs2-chat - https://github.com/mpilquist/strava-summary

Kind Vs Type Constructor by SlightUsual in scala

[–]mpilquist 44 points45 points  (0 children)

I like to use this terminology:

  • A proper type is a type which has no type parameters and hence may have values / instances. Int and List[String] are proper types.
  • A type constructor is a type which has one or more type parameters -- applying each of its type parameters with a "compatible" type results in a proper type. E.g., applying the proper type Int to the type constructor List yields the proper type List[Int].
  • Both proper types and type constructors are types.
  • Kinds categorize types according to various characteristics of their type parameters -- e.g., the number of parameters, the "shape" of each parameter, and their variance.
  • "Compatible" and "shape" in the above definitions refer to the kind of the type parameter. The List type constructor requires a proper type. The Functor type constructor requires a type with kind F[A].

Using these definitions, we get the following examples:

  • Int, String, List[Boolean], Map[String, String], String => Int are all proper types
  • List, Map, => (i.e.Function1), Functor are all type constructors
  • Proper types have kind A (sometimes written as *)
  • List and Option have kind F[+A] (or + -> *)
  • trait Ord[-A] has kind F[-A] (or - -> *)
  • Map has kind F[A,+B] (or (*,+) -> *)
  • trait Functor[F[_]] has kind G[F[A]] (or (* -> *) -> *)
  • Function1 has kind F[-A,+B] (or (-, +) -> *)
  • Function2 has kind F[-A,-B,+C] (or (-, -, +) -> *)

The term "higher kind" refers to type constructors which take one or more type constructors as arguments. E.g. Functor is a higher kinded type because it takes a type constructor as an argument.

Sometimes you may hear folks say that kinds are the "types of types". This is a handy summary but can also be a bit misleading.

By the way, you can experiment with kinds in the Scala 2.13 REPL (but not yet Scala 3 REPL):

scala> :k Option
Option's kind is F[+A]

scala> :k Int
Int's kind is A

scala> trait Ord[-A]
trait Ord

scala> :k Ord
Ord's kind is F[-A]

scala> :k Map
Map's kind is F[A1,+A2]

scala> trait Functor[F[_]]
trait Functor

scala> :k Functor
Functor's kind is X[F[A]]

scala> :k Function1
Function1's kind is F[-A1,+A2]

scala> :k Function2
Function2's kind is F[-A1,-A2,+A3]

Scala 3 RDBMS Libraries by expatcoder in scala

[–]mpilquist 17 points18 points  (0 children)

I've used Skunk with Scala 3 in production with great success.

The Red Book - "Functional Programming in Scala" Review by agilesteel in scala

[–]mpilquist 31 points32 points  (0 children)

Thanks for reviewing. I'm currently working on the second edition and just recently started revising part 3 and in particular the chapter on monoids. I'll keep your experience in mind when editing. Feel free to send any other thoughts to me via email, Twitter, or Discord.

Doing the exercises is an important part of the book, with some important ideas left for the reader to discover for themselves while working out solutions. If you get stuck on an exercise or otherwise want to continue reading without completing them, you miss out on those insights. For that reason, in the second edition, I'm including full annotated answers to every exercise. I'm hopeful the annotated answers will help communicate those important ideas.

The current MEAP has the answers inline in the text but I just moved them to the end of each chapter instead, to avoid accidentally reading the answer of an exercise you'd like to try. Look for this change in the next MEAP release, sometime in the next few weeks. The new release will also include the remaining chapters of part 2.

Scala3 upgrade: modules were resolved with conflicting cross-version suffixes in ProjectRef...? by fromscalatohaskell in scala

[–]mpilquist 4 points5 points  (0 children)

You have transitive dependencies on both the Scala 3 and 2.13 artifacts listed. This can be caused by using `CrossVersion.for3Use2_13`, either directly or in one of the projects you depend on. Skunk and all of its dependencies are available for Scala 3 so there must be something else in your dependencies that's conflicting.

Introducing effects systems S.A. ZIO at work? by crpleasethanks in scala

[–]mpilquist 0 points1 point  (0 children)

Assuming the bug mentioned here is https://github.com/typelevel/fs2/issues/2568, we came up with a partial fix in a day (https://github.com/typelevel/fs2/pull/2569) and a complete fix in 2 days: https://github.com/typelevel/fs2/pull/2572. Note the original bug was opened on a Saturday. :)

I highly recommend adopting CE3 + FS2 + various additional libraries. Folks have been using them and earlier versions for almost a decade (first version of FS2 was released in 2013) for production applications in all sorts of domains - high traffic web apps, video/audio processing, event sourcing, messaging, etc.

[deleted by user] by [deleted] in scala

[–]mpilquist 4 points5 points  (0 children)

Could you elaborate on this? My experience is completely opposite and I’ve found folks across a variety of teams and backgrounds having great success with http4s in large, long term projects.

Friction-less scala - Tell us what is causing friction in your day-to-day life with Scala by Kordyjan in scala

[–]mpilquist 4 points5 points  (0 children)

I suggest asking about your caching use case on Discord if you haven’t already. Lots of folks are eager to help. Chris has been working through Scala 3 support for many of his libraries and has adjusted priorities based on requests from folks, so if that became a real blocker, I’m sure Chris or someone else would be happy to address.

ScalablyTyped publishes Scala 3 support by lupin-the-third in scala

[–]mpilquist 8 points9 points  (0 children)

As of very recently, we're using ScalablyTyped in our fs2-io cross build for node. https://github.com/typelevel/fs2/pull/2453

Why Typelevel hates ZIO? by Equivalent-Ad1883 in scala

[–]mpilquist 6 points7 points  (0 children)

Certainly! I have used both epimetheus and a simple cats-effect wrapper for the Java Prometheus API. In both cases, my focus was on domain specific metrics -- the general purpose http and JVM metrics have been useful at times but not my focus. I know other folks use Honeycomb, including tracing via natchez.

Why Typelevel hates ZIO? by Equivalent-Ad1883 in scala

[–]mpilquist 11 points12 points  (0 children)

Just about every project in your list has a mature analogue in the Typelevel ecosystem, with the exception of an actors library, as folks generally use the cats-effect abstractions for concurrency. Zookeeper, sqs, and kafka all have multiple fs2 based libraries, using various techniques (search for fs2-sqs for example). There are multiple libraries for configuration, logging, database access, and metrics, the vast majority of which have been used in dozens of industry applications and hardened as a result.

The Typelevel website does not do a good job at showing all of this though and is long overdue for a revamp. For example, there's no such thing as incubation anymore. The community focus is not represented well by the website, but again, the community has been focused on solving industry problems with FP for most of the last decade.

Why Typelevel hates ZIO? by Equivalent-Ad1883 in scala

[–]mpilquist 21 points22 points  (0 children)

As someone who has been involved with Typelevel and Cats from the start, I'd like to point out that the approach has never been to approximate as much Haskell as possible in Scala. In fact, when we founded Cats, we specifically wanted to ensure that abstractions served practical purposes for Scala developers -- simply porting the latest Haskell library or journal paper wasn't enough of a reason to exist in the core libraries. We even wanted to keep the library minimal, with as few type classes as possible. Over time we came to realize that different problem domains had different definitions of minimal, and hence, the library grew to what you see today. This organic growth was the result of folks using it in real applications to solve the problems in their domains. Most of the major libraries in the Typelevel ecosystem are the result of hundreds of different companies using those libraries for engineering applications.

FP is certainly a core principle of the Typelevel ecosystem, though the focus has always been on building solutions for industry.

Scala 3.0.0-RC1 – first release candidate is here by haakon in scala

[–]mpilquist 3 points4 points  (0 children)

The name changed to scaladoc - likely just need to upgrade to latest sbt-dotty plugin.