From owner-freebsd-hackers@freebsd.org Sun Jan 6 13:09:11 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 91A21148EAC0 for ; Sun, 6 Jan 2019 13:09:11 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (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 2EAB2764DB for ; Sun, 6 Jan 2019 13:09:10 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by mail-ot1-f47.google.com with SMTP id 32so35665923ota.12 for ; Sun, 06 Jan 2019 05:09:10 -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=KQrMcaQZ3XdZiCA91PLQCdsGaQfQodCNCbuQd+DR0Fk=; b=E77b8CCtzPvSAyQuytgctWohRnLoxRdV2ZmpSwDhBeKBP4D+9gMoKrs4MjrPV5gzRz dLq0+7p26YKICGTpTQWqJju15R5r93bos8qS5rrsDwUfHXnKICjCKtGaYCpsqIXLHDDP NnuienaxIHq1b9WHyG53evxZSvP06t03PiUlT5JJlyVaZwoCo9d8LQI5lWO4iGVdipSY MjH6GOCmRWFF9a+YG62EGvxElDdhtUG8sVrM4yKOcNnxwYopjLbyeUe8jtNEHW1rA89g tRcCl/EclS8qLOBSJF93UBBEqTrBt2xKpUaDJNb8UCRXKxQf4BKqKVjXOHix/eYqoOjQ O2yg== X-Gm-Message-State: AJcUukcm1LbpP7qBu144/DmnNltd1gTz1IFSihmfaPZWhfYFGON/Hvtq E3Od16YPqN/Jh69k1xs8N1wYDvB+2aTd5j4YhgvEKw== X-Google-Smtp-Source: ALg8bN6oXEdLtHXa2ZN1B0GkmN6ugN2Vv1FnSaVzLsuLr8NFPFdJWEhIa2G1jDbUWJNsi3Ryr7J6rJGNR/kT7awa6qo= X-Received: by 2002:a9d:4c01:: with SMTP id l1mr40703290otf.242.1546780141705; Sun, 06 Jan 2019 05:09:01 -0800 (PST) MIME-Version: 1.0 References: <201901021829.x02IT4Kc064169@slippy.cwsent.com> <361CCB81-AEB6-4EAC-9604-CD8F4C63948C@gmail.com> <6DF138FB-E730-477A-A992-8FE1944DDE94@exonetric.com> <451787DE-0659-4F7D-B011-904F90866DDB@gmail.com> In-Reply-To: From: Igor Mozolevsky Date: Sun, 6 Jan 2019 13:08:25 +0000 Message-ID: Subject: Re: Speculative: Rust for base system components To: David Sid Olofsson Cc: Hackers freeBSD Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 2EAB2764DB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of mozolevsky@gmail.com designates 209.85.210.47 as permitted sender) smtp.mailfrom=mozolevsky@gmail.com X-Spamd-Result: default: False [-4.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[hybrid-lab.co.uk]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[47.210.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.97)[-0.966,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[igor@hybrid-lab.co.uk,mozolevsky@gmail.com]; 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]; IP_SCORE(-1.22)[ip: (-0.59), ipnet: 209.85.128.0/17(-3.78), asn: 15169(-1.67), country: US(-0.08)]; 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: Sun, 06 Jan 2019 13:09:11 -0000 On Sun, 6 Jan 2019 at 11:43, David "Sid" Olofsson wrote: > > Rust features several limitations on pointer usage by default that increase > memory safety by forcing you to write a safe solution. (They are pretty > interesting, I recommend looking into it.) Rhetorical: remind me what Java's pointer usage policy is again? > It is indeed dependent on some "unsafe" libraries to function and there may > be exploits in those (Literally applicable to all languages. What is machine > code if not a library?), but from what I've gathered you could write those in > rust as well using the @unsafe flag. (This probably yields better safety than > the c++ glue slapped together by a java programmer to "get the JVM to run, > goddammit!". But that isn't really the point.) Probably? If you don't know one way or another, why even speculate??? > By moving the bulk of your application out of "unsafe" c or c++ and into > heavily type checked, ownership oriented and abstracted rust you would > reduce the potential bugs without the performance reduction and large > runtime required by java. Don't know where you've been for the earlier discussion, but someone did an experiment, and guess what: Rust yielded a massive increase in instruction count for a a simple sum-of-integers program, so it's not just "runtime library" issue. As for "potential bugs," see below. > Rust isn't a silver bullet that will fix all bugs. It is a slightly more > abstracted and type checking language that is slightly better for a lot > of things. If you don't find that slight improvement worth the difficulty > it is to learn it, then don't. An inept craftsman always blames the tools: wrong screwdriver, wrong hammer, wrong language. Learn the discipline of programming, learn to identify tainted inputs, learn to identify your own assumptions, learn to verify your own assumptions before relying on them, learn the architecture you're writing the code for, and learn the language that you're using. Most buffer overflows in C, if not all, are simply are a result of ineptitude, for example---not because C has bad libraries, but because the person using them (a) didn't understand the ramification of using a specific library call, (b) failed to identify all assumptions they relied on, and, consequently, (c) failed to verify the assumptions before relying on them. Ditto for format string exploits. The gist is: learn a better discipline of programming to make better code, not yet-another-many-promises-but-few-deliveries language. -- Igor M.