From owner-freebsd-hackers@freebsd.org Tue Jan 1 00:54:31 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A91D51421485 for ; Tue, 1 Jan 2019 00:54:31 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com [209.85.210.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EE7B8CF15; Tue, 1 Jan 2019 00:54:30 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by mail-ot1-f48.google.com with SMTP id f18so24310457otl.11; Mon, 31 Dec 2018 16:54:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XyuIE1BpkOuCHCCpf1cqU2DXlsjxIutyceR97GlCoAU=; b=VJtdMqA5S6fO1VSDF9ROk2uuDbAaJtdiCcrhQu/O5d3a+EJcVTYWqJJkPW1f9dqXFF bzpWEF0z8qHQugZ7HcokKLsZhH2+BT7GWxSDtBxts076tVGco4Zn28JbqKUsHEZUkJjj 7npNml2ICVk6141YWIZbL7GmVZ2lRD1RXSMaZbVb9Ht12jzblFzF6odLRWs5KlZHAdkz DUA//nJVi3xKin22LPFXhD324rA03wI6Mx1Rlw/g0frwRTAJWgR6xWpXHdENvdqq1hcu kZ84dJzyXhuXfmSTBBw/rTJ9LoXWbrkY0t8q57mrwPZxNM9tfAbKQDLxRhpVLHi6nc64 30hw== X-Gm-Message-State: AJcUukcZHQbW40yR3FQ5rUo1F+O2yMbHcoOv/KXqXGQwikOPYGrGEJpQ 1mMilSOr6EwAuc/QoM97y0/e+SAsETFIjDJGoBxQTA== X-Google-Smtp-Source: ALg8bN7QHA8EVf0DOIxshhv6P7kr0pxBTT3SQl6LhW4Jysec0uAixDGakaj5llkHiTHMe2s3/bkBIdr5X0wIodmXNf4= X-Received: by 2002:a9d:225:: with SMTP id 34mr28541070otb.224.1546304064377; Mon, 31 Dec 2018 16:54:24 -0800 (PST) MIME-Version: 1.0 References: <5B476178-4D09-486F-AC58-47CB04965335@FreeBSD.org> <2C39D05E-E855-4FCE-82CF-83EA4AE9F84A@FreeBSD.org> In-Reply-To: <2C39D05E-E855-4FCE-82CF-83EA4AE9F84A@FreeBSD.org> From: Igor Mozolevsky Date: Tue, 1 Jan 2019 00:53:48 +0000 Message-ID: Subject: Re: Speculative: Rust for base system components To: Garance A Drosehn Cc: Alan Somers , Hackers freeBSD Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 9EE7B8CF15 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of mozolevsky@gmail.com designates 209.85.210.48 as permitted sender) smtp.mailfrom=mozolevsky@gmail.com X-Spamd-Result: default: False [-4.01 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[hybrid-lab.co.uk]; NEURAL_HAM_LONG(-0.99)[-0.994,0]; IP_SCORE(-1.19)[ip: (-0.55), ipnet: 209.85.128.0/17(-3.76), asn: 15169(-1.56), country: US(-0.08)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.82)[-0.822,0]; RCVD_IN_DNSWL_NONE(0.00)[48.210.85.209.list.dnswl.org : 127.0.5.0]; FORGED_SENDER(0.30)[igor@hybrid-lab.co.uk,mozolevsky@gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[igor@hybrid-lab.co.uk,mozolevsky@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2019 00:54:31 -0000 On Tue, 1 Jan 2019 at 00:30, Garance A Drosehn wrote: > There's two questions wrt performance. One is how long it takes > to compile some program, and then the other is how fast the > code is which is produced by the compiler. A note on both of > those: Rust has the notion of "building for release", in which > case the compile-time step takes *much* longer, but all that > extra time goes into producing better code in the resulting > program. Quite frankly the compile time isn't really *that* important, and longer (if not much longer) build times might push toward a better modularisation and compartmentalisation of the OS and the kernel so a small change in the kernel, for example, doesn't require the recompilation of the whole damn thing when nothing else is affected. *However,* in my experience various language "freebies" never truly come "free," the cheese a mousetrap springs to mind. And some of the "for"-reasons don't make much sense:- take the no need to alloc/free memory, for example, the only way to guarantee that it is really free is for some static analysis to envisage every plausible path the code takes and insert the appropriate statements in the appropriate places... *BUT* if you can do that in a static analyser, why not just run the static analysed against c-code and let it flag up bugs instead? > There's one program written in rust which I use a lot, which is > called 'ripgrep' (or 'rg' for short). It's one of the few programs > which I install via pre-compiled pkgs, because I don't want to wait > for all the time it takes to compile a release-build. But I'm very > happy with how fast the program runs. And what metric is that against? I'm very happy with the speed jQuery is executed in my browser, but that's no reasonable metric to argue that JavaScript is a suitable language for the kernel... -- Igor M.