From owner-freebsd-hackers@freebsd.org Tue Jan 1 16:23:00 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 2EE7A141F7BC for ; Tue, 1 Jan 2019 16:23:00 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 13F5275267 for ; Tue, 1 Jan 2019 16:22:58 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id CEC781604A; Tue, 1 Jan 2019 17:22:56 +0100 (CET) Date: Tue, 01 Jan 2019 17:23:16 +0100 From: Steffen Nurpmeso To: Bakul Shah Cc: Rozhuk Ivan , "freebsd-hackers@freebsd.org" , Volker Lendecke Subject: Re: Speculative: Rust for base system components Message-ID: <20190101162316.wa1vN%steffen@sdaoden.eu> In-Reply-To: <20190101015536.A54DF156E410@mail.bitblocks.com> References: <20181231160738.j4gow437liu7urjy@sernet.de> <20181231221030.6471937e@rimwks> <20181231201423.mJwUS%steffen@sdaoden.eu> <20190101015536.A54DF156E410@mail.bitblocks.com> Mail-Followup-To: Bakul Shah , Rozhuk Ivan , "freebsd-hackers@freebsd.org" , Volker Lendecke User-Agent: s-nail v14.9.11-123-g49d1a5c2 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 13F5275267 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [-0.13 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.90)[-0.899,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+a]; NEURAL_HAM_LONG(-0.75)[-0.746,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.83)[0.827,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: sdaoden.eu]; MID_CONTAINS_FROM(1.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; FREEMAIL_CC(0.00)[gmail.com]; IP_SCORE(-0.00)[country: DE(-0.01)]; 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 16:23:00 -0000 Bakul Shah wrote in <20190101015536.A54DF156E410@mail.bitblocks.com>: |On Mon, 31 Dec 2018 21:14:23 +0100 Steffen Nurpmeso \ |wrote: |> Rozhuk Ivan wrote in <20181231221030.6471937e@rimwks>: |>|On Mon, 31 Dec 2018 17:07:38 +0100 |>|Volker Lendecke wrote: |>| |>|> Not being involved in FreeBSD but in Samba, I could see a migration of |>|> parts of Samba to Rust if it had a Rust->C translator. I think for |>|> FreeBSD base components similar arguments would apply. You could ship |>|> the C output for the platforms that don't have native Rust. |>| |>|Rust is modern geeks toy by mozilla. |>|Just waste ot time, without any real profits. |> |> I vote for Nim (former Nimrod is no more). | |So do I but it doesn't make sense to add any new language to |the base system without having a number of absolutely |essential programs written in that language that must also be |included in the base system. Even at that point, using any |such language for writing kernel code is madness. There are |millions of lines of C kernel code which are not going to |benefit in any way from the new language. Remember that except |for drivers the kernel is essentially a single binary. GC |becomes much less of an issue for user programs. Of course not (imho), why not?, kernel-me? no!, and bloats of undocumented sysctl knobs there too!, and a very large one! Yes, nim uses gc. It is converted to native C[/C++/JavaScript] and then compiled. Oh - i for one would wish that C++ would be nothing than a layer on top of the current ISO C standard (weird enough), and could be dispatched in a C++-preprocessed form, so that TinyCC, pcc and all the rest could be used to compile it. (Not on FreeBSD of course, where those are broken, or were once i last tried.) All i was saying is that Julia and Nim are good languages. I like the latter the most. It is for real-life programmers. |I'd rather see a much smaller base, with pkg install for |various typical user types. Things get damaged. Things get broken. And i am almost away. (I have no Phabricator account.) I shake my head often. Unforgotten for example the claim "multi-column layout seems to have never worked" from a core team member when some old but great document by some "danish dynamite" has been thrown away (to packages). I seem to remember it that way (sorry if false). I am not an administrator, and i am almost not using perl anymore for new things, there are not many of those, and if i try to go sh -> awk -> perl and seldom have the needs to reach the end of that pipeline. But perl is a text processing language with full Unicode support and no doubts is a helpful hand to many, take email and you find git send-email (not me however), spam checking, dkim and other such server side stuff. Log parsing. An admin needs something, you hack it out of the box, from within the box. Now as a package, i seemed to have understood the reasoning. About this thread: i would have understood on April 1st. Ciao, require the last for the things which i need to do Aren't there 100000 packages already? --End of <20190101015536.A54DF156E410@mail.bitblocks.com> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)