Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 05 2019 14:43
    @typelevel-bot banned @jdegoes
  • Jan 31 2019 21:17
    codecov-io commented #484
  • Jan 31 2019 21:08
    scala-steward opened #484
  • Jan 31 2019 18:19
    andywhite37 commented #189
  • Jan 31 2019 02:41
    kamilongus starred typelevel/cats-effect
  • Jan 30 2019 00:01
    codecov-io commented #483
  • Jan 29 2019 23:51
    deniszjukow opened #483
  • Jan 29 2019 23:37
  • Jan 29 2019 23:22
  • Jan 29 2019 20:26
    Rui-L starred typelevel/cats-effect
  • Jan 29 2019 18:01
    jdegoes commented #480
  • Jan 29 2019 17:04
    thomaav starred typelevel/cats-effect
  • Jan 28 2019 17:43
    asachdeva starred typelevel/cats-effect
  • Jan 28 2019 07:12
    alexandru commented #480
  • Jan 28 2019 05:45
    codecov-io commented #482
  • Jan 28 2019 05:35
    daron666 opened #482
  • Jan 27 2019 13:56
    codecov-io commented #481
  • Jan 27 2019 13:46
    lrodero opened #481
  • Jan 27 2019 05:47
    codecov-io commented #460
  • Jan 27 2019 05:37
    codecov-io commented #460
Michael Pilquist
@mpilquist
BTW ScalaTest 3.1 has removed the new generator stuff and will add back in 3.2. Hence, FS2 is stuck on a 3.1 snap release until the 3.2 rcs start
Rafi Baker
@BakerRafi_twitter
I was listining to Fabio’s talk on Fibers and have a question. If Async callback is key in implementing Fiber based operations and I see Async moved down below Concurrent in CE3 proposal, wouldn’t this be a problem?
Fabio Labella
@SystemFw
@BakerRafi_twitter mm, yes and no (in practice, no)
first of all, you could actually decouple async and fork by making fork a primitive operation in the AST which is interpreted by sending the io directly to the EC (with a Fiber-Like handle to avoid losing it)
however in the talk I was really keen to stress the link between those two concepts (and cats-effect IO does implement Start with an Async node)
now coming to your more specific question, the key question is whether:
  • Async extends Concurrent
  • Concurrent extends Async
  • they don't extend each other at all
all three choices offer interesting tradeoffs
Fabio Labella
@SystemFw
if you move Async below Concurrent, a few things can happen:
  • you can implement Concurrent without Async, without using real concurrency (you write a scheduler for concurrent actions that does the interleaving). This is nice but not the main point
  • you need the type that is Concurrent to also be Async to use the real implementation. But then if every Concurrent is Async, why not Concurrent <: Async (which is the current situation)? Well, because we'd like to take an F[_]: Concurrent constraint and know that we can have concurrent control flow, without also having the ability to do every possible effect ever (which Async <: Sync implies)
does the above make any sense? (the design space is fairly vast so it's a bit hard to summarise it without showing concrete code)
Rafi Baker
@BakerRafi_twitter
Yes, it does. Thanks for explaining.
Daniel Spiewak
@djspiewak
@SystemFw that's an immensely concise summary of why Async <: Concurrent is nice :-) much more concise than any of my plodding explanations have been
Fabio Labella
@SystemFw
I'll save it in my writings then :P
also current status: I'm going into a deep investigation of Haskell's masking. The initial summary in the CE3 proposal is for certain incorrect I'm afraid, I'm trying to understand how much of the complexity we can shed, and how much we cannot
Paul Snively
@paul-snively
I want a master class with @djspiewak and @SystemFw.
Jakub Kozłowski
@kubukoz
Masking?
@paul-snively don't we all?
Fabio Labella
@SystemFw
look at the docs from Control.Exception. It's in the context of cancelable/uncancelable regions (same idea)
bifunctor
@bifunctor
From the doc, I did not get it.
Jens Halm
@jenshalm
@bifunctor It deals with the scenarios where you want to safely group the effect-full acquisition and release of a resource (e.g. an InputStream) into a single type. It reduces the amount of plumbing and the opportunity for errors in the code that uses the resource (e.g. you cannot forget to close the stream). The tutorial section about Resource is a bit more detailed (and also compares Resource with Bracket): https://typelevel.org/cats-effect/tutorial/tutorial.html#acquiring-and-releasing-resources
Paul Snively
@paul-snively
You could say it’s an effectful, referentially transparent version of try/catch/finally.
Basically, a “resource” is something that must be acquired (like a socket connection), used (effectfully), and released whether used successfully or unsuccessfully.
Jakub Kozłowski
@kubukoz
@bifunctor if you like this kind of thing, I made a vid about Resource (and Bracket, if you want to understand how Resource works with multiple effect types): https://www.youtube.com/watch?v=m9cu4xUvrUs
Rafał Sumisławski
@RafalSumislawski
Hi
The docs of Blocker say that it shouldn't be passed implicitly (https://github.com/typelevel/cats-effect/blob/master/core/shared/src/main/scala/cats/effect/Blocker.scala#L31). What is the reason behind this recommendation? I used to pass it implicitly and haven't seen any obvious drawbacks so far.
Daniel Spiewak
@djspiewak
@RafalSumislawski Just general best-practices with implicits. Basically, implicit values should never hold state. The implications of this are pretty profound and far-reaching, and a lot of it comes from experience in violating this rule (and paying the price later). An analogous "best practice" is that you should never do something like implicit def strToInt(s: String): Int = .... You certainly can do this, and it'll work sometimes, but you would reject any PR that introduced something like that, wouldn't you? Same thing with implicit Blocker.
That was maybe too abstract. :-) It's hard to point to concrete examples of where implicit Blocker will bite you. I guess the best thing to look at is the frustrations that people often have around implicit ExecutionContexts in the Future ecosystem.
Blocker is similar
Daniel Karch
@danielkarch
@SystemFw I attended your talk at Scala World and you mentioned that the toy IO that you built there is not stack-safe. I have started playing around with the code from the slides and filled in the blanks ... and I'm having a hard time getting the stack to overflow. ^^
In what way isn't the IO from http://systemfw.org/Scala-World-2019/ stack-safe? Aren't Pure/FlatMap + the run loop essentially a trampoline?
Rafał Sumisławski
@RafalSumislawski
@djspiewak the most common issue I've seen with ExecutionContext is that a typical application needs more than one ec, this leaves a lot room for "accidentally passed the wrong one" errors. Typically an application needs just one Blocker wrapping an unlimited cachedThreadPool. A cached thread pool indeed has a state, but it's the kind of state that can't be observed. Compared to blocker, I see more risk in passing around implicit CountextShift, which typically boxes a limited thread pool, and through that limit the state (number of running tasks) of the thread pool can be observed (delayed execution) by a user of the context shift.
paul-snively-exa
@paul-snively-exa
I'd agree the warning generalizes to ContextShift.
That is, as @djspiewak said, "Basically, implicit values should never hold state."
Rafał Sumisławski
@RafalSumislawski
@paul-snively-exa and what do you think about the inability to observe the state of a Blocker backed by a cachedThreadPool? I used to view it as a technical/JVM detail of execution, one that just like allocations, stack size limit etc, doesn't need special handling.
Paul Snively
@paul-snively
My sense is I don’t want anything unbounded passed implicitly.
In this case, the reality is, you don’t have an unbounded number of cores.
paul-snively-exa
@paul-snively-exa
(Cue @djspiewak: "'Unbounded' is just another word for 'DOS attack.'")
Rafał Sumisławski
@RafalSumislawski
I expect the threads of blocker to spend most of the time blocked, not on the cores, but I see what you mean. The risk of the pool growing infinitly is a problem indeed.
paul-snively-exa
@paul-snively-exa
Exactly.
At some point, when developing services at scale, I think you get radicalized about managing scarce resources explicitly.
Rafał Sumisławski
@RafalSumislawski
Then maybe the recommended practice should be to use thread pools of limited size under the Blocker? I feel like the API and the docs kind of encourage the unlimited cachedThreadPool approach.
paul-snively-exa
@paul-snively-exa
I think so too, but that's why, I think, the "don't use it implicitly" warning is there.
That is, I'd add the warning to ContextShift rather than removing it from Blocker.
Rafał Sumisławski
@RafalSumislawski
I get it.
paul-snively-exa
@paul-snively-exa
tl;dr threads are a scarce resource.
But meh. I take your point, too, about expecting most of them to be blocked rather than actually consuming a core. That's not indefensible, any more than expecting not to OOM, acting as if memory were unbounded, is.
It's all trade-offs.
Fabio Labella
@SystemFw
I think you can apply the "implicit call site" strategy to this problem
(re: implicit Blocker)
same that applies to stateful tagless algebras
basically the idea is that passing things implicitly does not really cause issues, it's implicit instances that can be troublesome (because you can pick up the wrong one by accident)