The Feedback Issue
viktorklang opened this issue · 43 comments
Dear reader,
this is where you can make general comments on the blog, provide feedback and ❇️ 👍's ❇️.
Keep things civil, but I already knew you were going to do that anyway.
I really appreciate it. Very straightforward. It's like the VIM of blogs.
... oh 👍
Wouldn't it make sense to add these blog posts to scala-lang.org/blog?
👍 Short articles. I can read them immediately, they don't wait in my #toread backlog. Sometimes hard for a Scala beginner like me but the mental gym is always fois. Thanks
good stuff. Show off https://github.com/viktorklang/blog/commits/master.atom for those who'd want to follow in an rss reader.
@kjozsa :-) yes, that's a good one, I have that as a link in the README.md but I should really put that into every single post.
@gervaisb Thanks! That's exactly what I'm trying to do, I read tons and tons of blogposts so I'm trying to write posts that I'd like/enjoy to read too—respecting the readers' time :)
Great format, I like it! It would be awesome to have commenting built in—and github happens to offer this feature: if every blog post were a pull request then discussions would easily be possible even on individual paragraphs.
@rkuhn Now that's a terrific idea. I'll experiment with that for the next post!
Having had a taste of scalaz.concurrent.Task, I kinda wish that Futures would allow delayed execution (as in don't spawn a new one every time I map over one) in a similar manner.
(In fact, separating the concepts of defining an [not necessarily] asynchronous operation and running one is powerful.)
Am I being unreasonable?
@britter Thanks for the suggestion, I'm trying to see if I can stick to vanilla GH features for as long as possible. That makes it possible for me to have the same workflow I do for any coding :)
@megri Yes. Very unreasonable. ;-)
Jokes aside, scalaz.concurrent.Task is an interesting construct, and it would be nice to have something like that in the stdlib. One unanswered question is whether transducers would be enough.
@viktorklang in fact your workflow would stay absolutely the same, but the result would look much better. This is, because GitHub pages support jekyll natively. So you just set up the jekyll project in your repo, activate gh-pages and GitHub will automatically export your blog as gh-page. You would still simply wite your posts in markdown syntax, but it would look like a real website.
More information can be found in the GitHub documentation and the jekyll documentation.
HTH!
this looks like an awesome idea! no need to host, no need to setup, just write plain md files
i think it's very readable as is, and you don't need to read jekyll docs as a bonus :)
Now I like Scala Future, @viktorklang, a lot has changed since How C# beats Scala in async programming
@anicolaspp Thanks! I'm really glad you like them now :)
@jozic :) I wholeheartedly agree!
@britter Great points! I'll sleep on it and see if I want to take the Jekyll plunge one more time. :)
I notice you sometime show the types, but comment them out:
val someFuture: Future[String] = …
val lifted/*: Future[Try[String]]*/ = someFuture.transform(Try(_))
Why use a comment? Why not just declare the type?
@dwalend That's a great question and I hope I have a somewhat good answer:
I tend to want to emphasize when type annotations are not needed, since sometimes you need to be explicit in order to guide the type inferencer.
Thanks. That makes some sense, but I worry that innocents might cut and paste the code, then the comment rots toward being misleading. (In my own code I put type annotations whenever I spend more than a few seconds pondering it, and for all but the most obvious types in example code. I don't think I'll ever get your level of sophisticated readers.)
This means that global will have at most scala.concurrent.context.maxThreads + scala.concurrent.context.maxExtraThreads concurrent Threads.
Would "at most scala.concurrent.context.maxThreads" (and not more) be better? Will people find scala.concurrent.context.maxExtraThreads? Will they be astonished when it matters?
@dwalend I was considering writing a post on "Configuring the global ExecutionContext", do you think that'd be interesting?
Definitely. Also, if you write something that reads as strangely as "...maxExtraThreads" , revisit the config code. (Maybe even "maxIOBlockedThreads" would be better. API control would be better than properties.)
@dwalend Where would you put said API control? :-)
ExecutionContext.global I suppose.
The harder question - what could turning the knobs actually do?
@dwalend Sure, but where would it be invoked? And what if multiple things tried to change it? :)
Classic awful mutable globally accessible state. They'd fight it out. Last in wins. And changes to the ExecutionContext.global doddle behind, trying to keep up. It'd be like one of those horrible control problems modelled by undergrads using Simulink.
It would stink, but it might be better than nothing. Then again, exposing anything beyond System.getProperty() it might brick you out of future innovations.
@dwalend Something like that, yes ^^
Future.firstCompletedOf could have an implementation with varargs.
Because Future.firstCompletedOf(f1, f2, f3) is simpler to read than Future.firstCompletedOf(Seq(f1, f2, f3)).
Sorry if this is the wrong place to make this suggestion.
👍 nice blog. Improving the symmetry of the APIs in Futures in Scala 2.12 is good, definitely helps. Looking forward to using the new swanky ACPS style.
Was wondering if the new thread names might be too long? W.r.t debugging live systems in a data centre with a 21" monitor for someone with poor eyesight.
@RayGit Thanks! :)
Regarding the thread names, I'm open for improvements, so feel free to suggest alternatives!
@viktorklang, thanks for the series! Will Future in Scala 2.12 eliminate the need to reimplement Futures in frameworks like this http://twitter.github.io/finagle/guide/Futures.html#futures?
Hi @shishkin,
Future in Scala 2.12 won't mitigate the reasons listed (especially not that last one ;)).
Futures in Finagle "conflate" the notion of a value, and the notion of a Task/Operation (which would be cancellable etc). In the future (no pun intended) the Scala Standard Library might feature a Task-representation, which would in that case be cancellable. (The problem with cancellation on the JVM is that it needs to be cooperative, and the problem of sticking that feature unto Future would make Future not read-only).
Does that help? :)
√
Thanks, perfect answer.
Part 9 has compilation error that's bugging me
acps(r.transform(result => Success(result :: list)), tail)
should be
acps(r.transform(result => Success(result) :: list), tail)
'future.flatten' is a great feature, thanks!
@betandr Thank you, i'm glad it's getting used! (It was getting harder and hard justifying flatMap(identity)) :)
Hi Viktor,
I have thought a few hours about promise linking and that complicated mechanism looks unnecessary for me. I've managed to fix the memory leak problem with a simple change - extracted creation of closure to another method. My post about that is here: https://groups.google.com/forum/#!topic/scala-internals/RtsPUliPNQA and the project with demonstration is here: https://github.com/tarsa/FuturesFix
What do you think about that? From my experiments it works. Without promise linking logic (but with that small fix) the source code of Futures and Promises would look much simpler and easier to follow.
Hi @tarsa!
I've replied to your email :-)
Hi @viktorklang
In Scala 2.13.0-M4 varargs are now immutable Seqs
https://github.com/scala/collection-strawman/wiki/FAQ
scala.Seq[+A]is nowscala.collection.immutable.Seq[A](this also affects varargs methods).
So Future.firstCompletedOf could be overloaded with a varargs alternative.