Date: Tue, 1 Jan 2019 00:53:48 +0000 From: Igor Mozolevsky <igor@hybrid-lab.co.uk> To: Garance A Drosehn <gad@freebsd.org> Cc: Alan Somers <asomers@freebsd.org>, Hackers freeBSD <freebsd-hackers@freebsd.org> Subject: Re: Speculative: Rust for base system components Message-ID: <CADWvR2gPF_xM4mDi-uuWq3C6qKh72Kn17=g6bOLPMYYHsayO8Q@mail.gmail.com> In-Reply-To: <2C39D05E-E855-4FCE-82CF-83EA4AE9F84A@FreeBSD.org> References: <ca76e5f7-6e59-bd67-144a-90ad66f0252e@metricspace.net> <CAG6CVpV0kxupmkhHiYBT05Yfst6uNtbUyYUzG95Zwcbk9F3K0Q@mail.gmail.com> <CAOtMX2gO5yMxLpZYxmfG3DFhRnZna-mQBOGXe=OJOzP4QfpBmg@mail.gmail.com> <5B476178-4D09-486F-AC58-47CB04965335@FreeBSD.org> <2C39D05E-E855-4FCE-82CF-83EA4AE9F84A@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 1 Jan 2019 at 00:30, Garance A Drosehn wrote: <snip> > 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? <snip> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADWvR2gPF_xM4mDi-uuWq3C6qKh72Kn17=g6bOLPMYYHsayO8Q>