From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id AEEC4138334 for ; Mon, 16 Sep 2019 08:11:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F3BB5E0968; Mon, 16 Sep 2019 08:11:45 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8A78AE0871 for ; Mon, 16 Sep 2019 08:11:45 +0000 (UTC) Received: from katipo2.lan (unknown [203.86.205.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: kentnl) by smtp.gentoo.org (Postfix) with ESMTPSA id A8D4234B1FD for ; Mon, 16 Sep 2019 08:11:43 +0000 (UTC) Date: Mon, 16 Sep 2019 20:11:34 +1200 From: Kent Fredric To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass Message-ID: <20190916201134.765fdd20@katipo2.lan> In-Reply-To: <4050b216-b3fb-b444-4d88-7e7211804f4d@gentoo.org> References: <20190911172128.18885-1-williamh@gentoo.org> <20190911172128.18885-4-williamh@gentoo.org> <20190911234815.GA21591@whubbs1.dev.av1.gaikai.org> <20190912154634.GB23846@whubbs1.dev.av1.gaikai.org> <88094567-323c-6f6a-a1d9-0c1b77ef53e3@gentoo.org> <6acd490e-6393-62e4-5d07-71c2a3624417@gentoo.org> <4050b216-b3fb-b444-4d88-7e7211804f4d@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/iei5Ro7DDUiG9drfmifz7TR"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Archives-Salt: 8be766ee-ae5b-48d9-95f7-367e3df7ba7b X-Archives-Hash: bc506e1655a8128fa5cb9f0bcc2ea00c --Sig_/iei5Ro7DDUiG9drfmifz7TR Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 13 Sep 2019 12:50:48 -0400 Michael Orlitzky wrote: > The rule "don't copy and paste code" applies to your > linker just as much as it applies to the first program you wrote in > CS101, and for the same reasons. My experience has taught me to ignore the rule as written, and consider it more a guideline aimed at novices. Importantly, don't copy and paste code you don't understand. However, if you re-use a given implementation, you can sometimes become dependent on specifics in that implementation. And upstream have an annoying tendency to change implementation details in incompatible ways. This breaks your code, sometimes obviously, sometimes subtly. So the benefit you'd hoped to attain by modularity only remains true if the modules in question are immutable for the problem you're using them for. Also, these external modules bring with them complexity you may not want or need (and their own dependencies with the same issues), and that's not free either. Subsequently, when considering a new dependency, I have to ask questions about whether I can implement a subset of the dependency faithfully that suits my needs, and ask if I have the skills to be an expert in this implementation. A level of distrust in the people who author and maintain your dependencies is something I consider healthy. Does this map at all to static linking? You bet. And that's part of why Go and Rust use it. The fragility of other-peoples code in the long view of time is high, because with dynamic linking, you don't have any guarantees about integrity. You have to cross your fingers and hope upstream so-named their libraries right, hope upstream changed their API markers right, hope upstream never accidentally made a breaking change without changing an API marker, hope your code doesn't need a mountain of work to recompile after the API marker changes, and hope upstream/gentoo maintainers for your package can still be bothered to ship fixes for the API consumer. That last paragraph sums up a large volume of the daily hell of being a maintainer and a gentoo user. Static linking is more a result of a sickness, not the sickness itself. --Sig_/iei5Ro7DDUiG9drfmifz7TR Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEgdrME8Lrmai3DXYJda6SGagVg7UFAl1/Q7YACgkQda6SGagV g7VR2w//Rcu2kl2+Fgu9KtvWUrXeANk6XDjcYbMXCkCuekVoKX8KWnz7CJZ30wbj Mh4UMB1yIRhVo2i0MasfgT8ge0PISKGjzLZS2Ccx2ZBUoalnwZ1pOqo/vRkxpzfJ JKrRrrRjfZF4uZT6HGAf6QDGXgLD0OAlENkqZSSjWz4+lf/XyceQpM7izN7O+fMZ UunH8UO3v/1TYvIMl5ovgWKVGjBltDcIZXWslIRtNcgvUwc7IKDF8bERokziYooZ p7jFVxbpArP4tLj7GlNe2iw4J3UgSViPo14WF5O6HvnzmludzfGmm4eEO7uK4Oli UR6dWf143Mg6Yf5EMxCrAZKuhYGnG5YCC7mpoUtGjtDR3Bcx+Zrlb8JI6409kGDv Fx+Aj2dxTiJioNWVKeq2bxI7wv4pdviaEB18AtGqOW9qnxY1FsajyJh32Fmh2asy QdFox7qHR4PHmKPlPfmHuSssl935jG1LoOCWdTm6CmUzfAWK4W9673jIZbGdji6S 93TjkEQ+9kViMYwrgY47SFrMIVLu0mi2S/ArUGJYw0TYhJK5yOEaLszEs9yurqVl NkyKrg+vLHK++FJ7BxFg9Emt72smqUXz7hZxQt7oBDvLUr1bzkxCtOuQqh6EYRs8 jHPonlDV2TvwtxWBqqzDdTzfU3xUJOFPEyoQCWy78KkgHQyo0/E= =pVR+ -----END PGP SIGNATURE----- --Sig_/iei5Ro7DDUiG9drfmifz7TR--