From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Concurrency, again Date: Wed, 26 Oct 2016 10:03:54 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87zilr5hrp.fsf@lifelogs.com> References: <87wq97i78i.fsf@earlgrey.lan> <86k2dk77w6.fsf@molnjunk.nocrew.org> <9D64B8EA-DB52-413D-AE6A-264416C391F3@iotcl.com> <83int1g0s5.fsf@gnu.org> <83twckekqq.fsf@gnu.org> <83funkwfzf.fsf@gnu.org> <87k2cwe4wl.fsf@jupiter.lan> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1477490762 10591 195.159.176.226 (26 Oct 2016 14:06:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Oct 2016 14:06:02 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 26 16:05:57 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bzOpl-0008JW-LC for ged-emacs-devel@m.gmane.org; Wed, 26 Oct 2016 16:05:37 +0200 Original-Received: from localhost ([::1]:34849 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzOpo-0000mM-23 for ged-emacs-devel@m.gmane.org; Wed, 26 Oct 2016 10:05:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33905) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzOol-0000jh-HH for emacs-devel@gnu.org; Wed, 26 Oct 2016 10:04:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzOoh-0001i4-Fr for emacs-devel@gnu.org; Wed, 26 Oct 2016 10:04:35 -0400 Original-Received: from [195.159.176.226] (port=60555 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bzOoh-0001hZ-9C for emacs-devel@gnu.org; Wed, 26 Oct 2016 10:04:31 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bzOoP-0007oX-UB for emacs-devel@gnu.org; Wed, 26 Oct 2016 16:04:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 33 Original-X-Complaints-To: usenet@blaine.gmane.org X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Cancel-Lock: sha1:HCtrc9hQsz2HtJv+l8tzepQbJ7g= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:208839 Archived-At: On Tue, 25 Oct 2016 19:04:42 +0200 Stefan Huchler wrote: SH> Are you willing to invest much time in implementing your solution? It seems SH> to be similar to the commercial world, where people say "put your money SH> where your mouth is", just in this case "put your code where your mouth SH> is". SH> I think people would be more convinced if there is some commitment, SH> cause else you can formulate the nicest thing and nothing will happen. Commitment and personal investment are not enough to make a code change convincing. Please don't forget that writing code is a small (10-15%) part of the overall cost. Documentation, backwards portability, handling bugs (including bugs caused by poor documentation or poor API design!), technical debt, and ongoing maintenance are costs that must be considered by the Emacs maintainers for any proposed change. The scope, therefore, matters: the wider the scope of the change, the more risk and cost it may incur. In that light, I think Philipp's proposed libtask wrapper may be a good direction because the risk is low (it relies on existing well-known libraries) and the cost is low (it doesn't change internals significantly). Looking at the concurrency-libtask branch, the API design of the channel piece, at least, seems reasonable: it's well-known to Go programmers and provides a nice message bus facility. I don't know how Philipp's proposal interacts with the other concurrency proposals, though. HTH Ted