From nobody Thu Sep 12 01:51:28 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X40mM5gzCz5WDwr for ; Thu, 12 Sep 2024 01:51:47 +0000 (UTC) (envelope-from d@l.ynx.fr) Received: from mailer.daserv.fr (daserv.fr [91.121.223.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4X40mL1CRtz4jYd for ; Thu, 12 Sep 2024 01:51:45 +0000 (UTC) (envelope-from d@l.ynx.fr) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ynx.fr header.s=YNX_KEY header.b=hMEE8zeP; dmarc=pass (policy=reject) header.from=ynx.fr; spf=pass (mx1.freebsd.org: domain of d@l.ynx.fr designates 91.121.223.74 as permitted sender) smtp.mailfrom=d@l.ynx.fr Received: from [127.0.0.1] (unknown [192.168.199.7]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mailer.daserv.fr (Postfix) with ESMTPSA id 02A42874D for ; Thu, 12 Sep 2024 03:51:35 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 mailer.daserv.fr 02A42874D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ynx.fr; s=YNX_KEY; t=1726105897; bh=ft7REDbherQXRazCvxC/RLqmy3XNrx23cRzuXuJJvac=; h=Date:From:To:Subject:In-Reply-To:References; b=hMEE8zePZ3ioBpN+hRT6DPMezBegydWasm2JedGh2VTHwEFw+EliMwiERFaRhwdpR eXV9aaGcL8+DgljKNzGDsXThkgJgV8gxoEnbQ20n0xNBznBofjbn7bkM2x65QkxlJ8 bUymSS8fGaXBiS0exqYwvfhUdko9XNN3u7Ffopao= Date: Thu, 12 Sep 2024 01:51:28 +0000 From: DaLynX To: freebsd-hackers@freebsd.org Subject: Re: Some rather stupid questions about Rust and FreeBSD In-Reply-To: References: Message-ID: <2B36D92F-FC9F-488E-85E1-978D67F5BE24@l.ynx.fr> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----M8FKJ23YGJG3QUX0RL3T45WV8U17VS Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.90 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ynx.fr,reject]; R_DKIM_ALLOW(-0.20)[ynx.fr:s=YNX_KEY]; R_SPF_ALLOW(-0.20)[+ip4:91.121.223.74]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ynx.fr:+] X-Rspamd-Queue-Id: 4X40mL1CRtz4jYd ------M8FKJ23YGJG3QUX0RL3T45WV8U17VS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 12 septembre 2024 00:11:03 UTC, Aryeh Friedman a =C3=A9crit : >On Wed, Sep 11, 2024 at 7:02=E2=80=AFPM Alan Somers wrote: >> >> in Rust >> =3D=3D=3D=3D=3D=3D=3D >> let mut arr =3D vec![170, 45, 75, 90, 802, 24, 2, 66]; >> arr=2Esort(); > >The fact the data structure even worries about behaviour instead of >being passable to objects is asking for it (this is from my software >engineering hat)=2E Also the fact there is no explicit size of the >array defined since if it is static a Turing complete process can be >implemented on it but if it is dynamic how do you keep from >overflowing the storage allocated to it (aka buffer overflow)=2E > >> * The size of the array > >Very good idea from the resource management POV > >> * The size of each element > >Again correct call for an OS level language=2E > >> * The name of the comparison function > >Separation of concerns *STANDARD* software engineering=2E > >> >> Each of those is error-prone=2E Stuff like that is a common source of >> bugs in C code=2E But Rust tracks it automatically=2E > >At the cost of coupling stuff far too tightly it appears=2E > Hi, I am more of an IT security guy by trade and just do programming for fun b= ut I have played with Rust=2E I think your worries are very legitimate but = come from a lack of knowledge or understanding of the language=2E - Size questions are not absent from the language=2E They are explicit=2E = Even more than in C (I do not need to know the arch to know that an u32 is = 32 bit and a u64 is 64=2E)=2E They do not appear at the sort function level= because it is automatically taken into account by the compiler through typ= ing=2E - The vector we are looking at here (which technically is automatically ty= ped as a Vector, I believe) is a container class, pretty much like the= STL's vector in C++=2E It keeps track of its length (and capacity, whic= h you can also work with if you need to be precise about that)=2E - You seem to worry that the sort function is implemented at the data stru= cture level, like you would do by putting a method in a class, coupling too= tightly to your taste behaviour with structure=2E This is not really the c= ase=2E Rust works with traits: there is an Ord trait, for which you provide= an implementation for the types you want to work with, then the sort funct= ion automatically applies to any type implementing that trait=2E You seem to think the sort function is defined in the vector's class becau= se you look at the "=2E" like it accessed the member of a C struct=2E It is= not=2E That's just syntaxic sugar=2E The sort function is implemented sepa= rately, agnostically, taking anything that implements the Ord trait as argu= ments=2E So that behaviour is totally separate from the data structure, and= applies to a Vector of anything that implements an Ord trait (a comparison= function)=2E (Actually you can work with a PartialOrd too if you don't have a total ord= er, with some extra precautions=2E) And of course you can just use vec=2Esort_by(f) if you want to provide a s= pecific comparison function that is different from the one in the Ord trait= for your data type=2E So if you prefer to keep the separation explicit tha= t way, you can=2E It's just coding guidelines=2E As I said, I think the points you raise are most pertinent and legitimate= =2E But making your opinion of another language just based on brief example= s sent to you by email will never be enough to let you construct a complete= , accurate and thus fair opinion of it=2E So to anyone who doesn't know rust I advise to take some time to look at i= t and play with it=2E That's how we all learn=2E I hope that's constructive=2E Kind regards, DaLynX ------M8FKJ23YGJG3QUX0RL3T45WV8U17VS Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Le 12 septembre 2024 00:11:03 = UTC, Aryeh Friedman <aryeh=2Efriedman@gmail=2Ecom> a =C3=A9crit :
= >On Wed, Sep 11, 2024 at 7:02=E2=80=AFPM Alan Somers <asomers@freebsd= =2Eorg> wrote:
>>
>> in Rust
>> =3D=3D=3D=3D= =3D=3D=3D
>> let mut arr =3D vec![170, 45, 75, 90, 802, 24, 2, 66]= ;
>> arr=2Esort();
>
>The fact the data structure even= worries about behaviour instead of
>being passable to objects is ask= ing for it (this is from my software
>engineering hat)=2E Also the fa= ct there is no explicit size of the
>array defined since if it is sta= tic a Turing complete process can be
>implemented on it but if it is = dynamic how do you keep from
>overflowing the storage allocated to it= (aka buffer overflow)=2E
>
>> * The size of the array
&g= t;
>Very good idea from the resource management POV
>
>&g= t; * The size of each element
>
>Again correct call for an OS l= evel language=2E
>
>> * The name of the comparison function<= br>>
>Separation of concerns *STANDARD* software engineering=2E>
>>
>> Each of those is error-prone=2E Stuff like th= at is a common source of
>> bugs in C code=2E But Rust tracks it a= utomatically=2E
>
>At the cost of coupling stuff far too tightl= y it appears=2E
>

Hi,

I am more of an IT security guy b= y trade and just do programming for fun but I have played with Rust=2E I th= ink your worries are very legitimate but come from a lack of knowledge or u= nderstanding of the language=2E

- Size questions are not absent from= the language=2E They are explicit=2E Even more than in C (I do not need to= know the arch to know that an u32 is 32 bit and a u64 is 64=2E)=2E They do= not appear at the sort function level because it is automatically taken in= to account by the compiler through typing=2E

- The vector we are loo= king at here (which technically is automatically typed as a Vector<u32&g= t;, I believe) is a container class, pretty much like the STL's vector<T= > in C++=2E It keeps track of its length (and capacity, which you can al= so work with if you need to be precise about that)=2E

- You seem to = worry that the sort function is implemented at the data structure level, li= ke you would do by putting a method in a class, coupling too tightly to you= r taste behaviour with structure=2E This is not really the case=2E Rust wor= ks with traits: there is an Ord trait, for which you provide an implementat= ion for the types you want to work with, then the sort function automatical= ly applies to any type implementing that trait=2E

You seem to think = the sort function is defined in the vector's class because you look at the = "=2E" like it accessed the member of a C struct=2E It is not=2E That's just= syntaxic sugar=2E The sort function is implemented separately, agnosticall= y, taking anything that implements the Ord trait as arguments=2E So that be= haviour is totally separate from the data structure, and applies to a Vecto= r of anything that implements an Ord trait (a comparison function)=2E
(Actually you can work with a PartialOrd too if you don't have a total or= der, with some extra precautions=2E)

And of course you can just use = vec=2Esort_by(f) if you want to provide a specific comparison function that= is different from the one in the Ord trait for your data type=2E So if you= prefer to keep the separation explicit that way, you can=2E It's just codi= ng guidelines=2E

As I said, I think the points you raise are most pe= rtinent and legitimate=2E But making your opinion of another language just = based on brief examples sent to you by email will never be enough to let yo= u construct a complete, accurate and thus fair opinion of it=2E

So t= o anyone who doesn't know rust I advise to take some time to look at it and= play with it=2E That's how we all learn=2E

I hope that's constructi= ve=2E

Kind regards,
DaLynX


------M8FKJ23YGJG3QUX0RL3T45WV8U17VS--