3 ms·
> They solved the function-coloring problem Not really, they've just made it super implicit. Any FFI calls are now implicitly coloured, same with anything CPU-
by orf 6y ago
> They solved the function-coloring problem
Not really, they've just made it super implicit. Any FFI calls are now implicitly coloured, same with anything CPU-heavy.
Like their approach to type annotations, I think this will be a mistake in hindsight.
- rdw 6y agoThis is gonna sound pedantic but I think it's not a coloring problem. Coloring is when syntactically a function has to change its own signature just because it started calling an inner function with the new color. That said, you're right in that one may have to make some changes to code to get around some new problems. The problem with FFI/CPU-heavy functions is that they prevent _other_ fibers from being scheduled while they run. If it becomes possible to implement work-stealing, then that would mitigate the problem. It would also be solvable by sprinkling "yield to scheduler" calls throughout such functions. Annoying and not always possible, but, since in these cases the signature would not change, technically not coloring.
- gpderetta 6y agoIt is not pedantic at all, you are completely right; if this implementation were to be classified as coloroing, then everything would be, including classic threads.
- ioquatix 6y agoRuby FFI has been experimenting with provided support for kicking external functions to background threads with a single keyword argument.
- lalaithion 6y agoIn a high level dynamic language with exceptions, there's already so many implicit "colors" to a function that I think this is still the right choice.
- svieira 6y agoThis "implicit coloring" is what's talked about in _Unyielding_ [1], which is the "explicit color is good" counterpoint to _What Color is Your Function?_ (though Unyielding predates WCIYF by about a year). [1]: https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html