From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id UBZIH3fK02Vr/wAA62LTzQ:P1 (envelope-from ) for ; Mon, 19 Feb 2024 22:39:03 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id UBZIH3fK02Vr/wAA62LTzQ (envelope-from ) for ; Mon, 19 Feb 2024 22:39:03 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=zancanaro.id.au header.s=k1 header.b=IS54yrYN; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=zancanaro.id.au ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1708378743; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=Ux0O66WA3i6iMa0Kje81aCOh1YKBJqG+ujlySMK+edo=; b=uoTrVCiKxV9oMDnMhlhBDjTqPjBvgO5rd4izmfYvvSStie5ft/q805JLale691tcWES32i zOGRBmZBc7UNOZqeNlM/ZpaOSMRoBkNTnMGru0FmxWCQcsx+Cs+jBnpU2sfL7h0JG9Xkbs TJaPpD8KUwwVhUINpcKjRJZeJuznPHQNFc9PWdH+Ucd8DZ5p+ONIBVbHRQfsA/KGn397t/ +bAKbCwrHLBPSYfGXK74CuADtW23gm3O+DGlhtmsQmm6R/wisgjg7OVhh5PCShXqn5WmpL B8QysUDvuJwQOJVz+c0AMWjqzET3Kj/FFpLWI8J8RvxfFo/PZYlrOCIOw8vJ6w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=zancanaro.id.au header.s=k1 header.b=IS54yrYN; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=zancanaro.id.au ARC-Seal: i=1; s=key1; d=yhetil.org; t=1708378743; a=rsa-sha256; cv=none; b=cuWYsUimfXUW36HM4wN4zk4vG5LB+2gWIDgQOudD4APe+dUTrkvaQOkhNEJsCpomABCQqP SvF6O0uTP9w9opVKz4qwae7+p/WbMA6XToQOFZo9EvB3ENqrY82kW86WIwdT7BmbR8Mngg i9sGSX3GZSgqX1DgkrXm80FA7/xitiyVq4TRkxR4N0PKKm22Ncd7kAcJaq+TgsXPKEr+l6 aqsn2YbipXo0urNZqoUiBIZHVdl9D1Z6ayoURpqUMWQw6VZRQGySAczEOOtghRyr3HOGlf CeLfL2TPD6OQ5GwQxkNPxH/2xy5e0MhW/8/7oHNzkL8SCdDOLbk8w7RTd917Aw== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 258C1185D4 for ; Mon, 19 Feb 2024 22:39:03 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rcBLD-0001K1-VB; Mon, 19 Feb 2024 16:38:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rcBLB-0001JR-IX for guix-devel@gnu.org; Mon, 19 Feb 2024 16:38:22 -0500 Received: from voltorb.zancanaro.id.au ([45.77.50.64]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rcBL9-0006ZM-5E for guix-devel@gnu.org; Mon, 19 Feb 2024 16:38:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=k1; bh=Ux0O66WA3i6iMa0 Kje81aCOh1YKBJqG+ujlySMK+edo=; h=date:references:in-reply-to:subject: cc:to:from; d=zancanaro.id.au; b=IS54yrYNn6btYboJmDxtSPyntnnYR7dfhr15T ghr8BFHLdC7MJkudjzfT0OKvNH8E4Ja/8jGlidI3Mgv9p7CiTFdzM28+9PUmMZSvoBfvKq diniN2lpTT1vR/EXj5TXMstEQX24N2PfoJGINMICWMF63JnVLIO4JopH2gVgFgfo= Received: by voltorb.zancanaro.id.au (OpenSMTPD) with ESMTPSA id af74bc32 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 19 Feb 2024 21:38:07 +0000 (UTC) From: Carlo Zancanaro To: Ryan Sundberg Cc: Steve George , guix-devel@gnu.org, r0man , Reilly Siegel , Maxime Devos Subject: Re: Proposal to turn off AOT in clojure-build-system In-Reply-To: (Ryan Sundberg's message of "Mon, 19 Feb 2024 10:13:09 -0800 (PST)") References: User-Agent: Gnus/5.13 (Gnus v5.13) Date: Tue, 20 Feb 2024 08:38:10 +1100 Message-ID: <87le7gp22l.fsf@zancanaro.id.au> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=45.77.50.64; envelope-from=carlo@zancanaro.id.au; helo=voltorb.zancanaro.id.au X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -8.50 X-Spam-Score: -8.50 X-Migadu-Queue-Id: 258C1185D4 X-TUID: 0cmF6JMUuoJy As someone who has worked as a professional Clojure programmer, I would like to add my voice in support of this: On Mon, Feb 19 2024, Ryan Sundberg wrote: > ... In my experience using AOT is the exception rather than the rule; > it is a nice optimization when practical for release engineering, but > typically the juice is not worth the squeeze. That is: the norm in the Clojure community is *not* using AOT, so there isn't any specific statement against it. It's just assumed that you won't use AOT unless you have a reason to do so. Reading the clojure.org page about compilation[1] with this in mind, we see four possible (although admittedly not exhaustive) reasons to provide AOT compilation: - to deliver your application without source - to speed up application startup - to generated named classes - to create an application that does not need runtime bytecode generation and custom classloaders I'm not convinced any of these apply across the board in Guix. Potentially for some libraries and applications it does, and so should be applied in those specific cases. The next statement on the page, after those reasons to use AOT is: "The Clojure compilation model preserves as much as possible the dynamic nature of Clojure, in spite of the code-reloading limitations of Java." Or, to read it another way: AOT compiled Clojure is not as dynamic as on-the-fly compiled Clojure. This isn't a bug in Clojure, this is how it is designed to function. It could be argued that it is a bug in the individual libraries to not work with AOT, but I think it's inappropriate for Guix to attempt to impose "AOT is the right way to do things" on Clojure libraries. That is not the norm in that community. As a personal datapoint: I spent three and a half years working on mission-critical Clojure libraries and applications, and I have never used AOT compilation in production. Carlo [1]: https://clojure.org/reference/compilation