Comparing Pascal and Rust

[lainz]

Hi, I'm Pascal user not Rust user, but I take a look on that language last days.

What I've seen is:
- Rust uses only struct with associated methods (no classes), in FPC we call it advanced records.
- The memory is "moved" and can be only one owner at a time. Seems that the simple assign of a variable just moves it, in FPC we copy the variable, so we have copies. Also in Rust there is only a single pointer to a single data at the same time. This says to help to prevent having a variable for example in threads and in other places, and change them at the same time.
- There are references as well. Seems that in FPC this can be const modifier in functions and procedures?
- The types are a bit more strict than in FPC, for example there is no type conversion automatically, say you assign an Integer to a Double, that's not directly possible.
- The memory is erased when the scope ends, say a function. Same in FPC I think.

Well that's the far I get now with that language.

I see some things:
- Advanced records are available in FPC. No difference there.
- The memory is in FPC by default a copy of that record, not a move. Is possible to do a move and that the first instance is not valid anymore in FPC? Like moving a record to other record, inside the same function and / or to another functions.
- Passing a reference can be done with const or var parameters. In Rust it will be "&" for const and "mut &" for var. So no difference there.
- The memory is erased as well in FPC, when the functions ends, that is what I understand, so no difference.

So, they say Rust is more safe. On my experience is just that the compiler is very smart telling you where are the possible bugs you're making when coding. Other than that I see no point of using Rust.

Like typescript and javascript, the only difference is the compiler preventing you doing invalid stuff.

There's a mode or can be added to FPC that will help to prevent bugs? I alredy see some in Lazarus code editor, like unused variables, not initialized variables, missing return in a function. A lot of warinings about conversions.

Well that's it, I'm not saying one languages is better than the other. But just saying that FPC has already features that make it similar to Rust.

[PierceNg]

Rust has an evangelism strike force. Pascal has not.

Someone will surely correct me if I am wrong: Pascal records are stack-based, classes are heap-based, objects default to stack but can be heap-based. Dunno about advanced records. Rust structs default to stack but can be heap-based. Are Rust structs directly equivalent to Pascal advanced records?

In terms of language features, most of the newer languages like Rust, Swift, Kotlin etc support nullable or optional types. Such types are supposed to help deal with the null reference, which inventor Tony Hoare has called his billion dollar mistake.

[MarkMLl]

Put another way, people who say Rust is good are basically praising Pascal-like functionality which they perceive as superior to C-like functionality.

- The memory is erased as well in FPC, when the functions ends, that is what I understand, so no difference.

Not quite. By and large FPC makes variables inaccessible when they go out of scope, but the memory- and this includes strings which have been used for passwords etc.- is not erased/blanked/wiped/zeroed/randomised.

MarkMLl

[dbannon]

......
By and large FPC makes variables inaccessible when they go out of scope, but the memory- and this includes strings which have been used for passwords etc.- is not erased/blanked/wiped/zeroed/randomised.

And that would be because blanking out very large blocks of memory can be a time consuming thing. But few of us would store a (eg) password in a huge data array, should fpc null out smaller allocations and leaving the huge arrays alone ?

OK, thinking out loud, suppose an ANSIString can be told to blank out its memory before it goes out of scope ?  ANSIString.NullOnFree : boolean = false    ?

Davo

[avk]

... but the memory- and this includes strings which have been used for passwords etc.- is not erased/blanked/wiped/zeroed/randomised...

Does Rust do that sort of thing?
And seems like Rust has managed to outperform C++ in syntax ugliness?

[MarkMLl]

......
By and large FPC makes variables inaccessible when they go out of scope, but the memory- and this includes strings which have been used for passwords etc.- is not erased/blanked/wiped/zeroed/randomised.

And that would be because blanking out very large blocks of memory can be a time consuming thing. But few of us would store a (eg) password in a huge data array, should fpc null out smaller allocations and leaving the huge arrays alone ?

OK, thinking out loud, suppose an ANSIString can be told to blank out its memory before it goes out of scope ?  ANSIString.NullOnFree : boolean = false    ?

Davo

This is the real risk:

Code: Pascal  [Select][+][-]

1. begin
2.   plain := GetNonEchoedPasswordFromUser();
3.   salt := GetRandomSalt;
4.   plain := salt + plain;
5.   crypt := Encrypt(plain);
6.   plain := RandomChars(Length(plain))
7. end;
8.  

That obviously overwrites the plain variable before it goes out of scope, but it still risks leaving the plaintext password on the heap since the string might be reallocated when it's salted and the original is not overwritten.

MarkMLl

[avk]

If you want a data type that cleans up when it goes out of scope, why not just create one?
For example:

Code: Pascal  [Select][+][-]

1. unit CharDynArray;
2.  
3. {$mode objfpc}{$modeswitch advancedrecords}
4.  
5. interface
6.  
7. uses
8.   SysUtils;
9.  
10. type
11.  
12.   TDynCharArray = record
13.   private
14.     FItems: PAnsiChar;
15.     FLength: SizeInt;
16.     procedure ReallocPtr(aNewLen: SizeInt);
17.     procedure SetLen(aValue: SizeInt);
18.     function  GetItem(aIndex: SizeInt): AnsiChar; inline;
19.     procedure SetItem(aIndex: SizeInt; aValue: AnsiChar); inline;
20.     class operator  Initialize(var a: TDynCharArray); inline;
21.     class operator  Finalize(var a: TDynCharArray); inline;
22.     class operator  Copy(constref aSrc: TDynCharArray; var aDst: TDynCharArray);
23.     class operator  AddRef(var a: TDynCharArray);
24.   public
25.     procedure Clear;
26.     property  Items[aIndex: SizeInt]: AnsiChar read GetItem write SetItem; default;
27.     property  Length: SizeInt read FLength write SetLen;
28.     property  Ptr: PAnsiChar read FItems;
29.   end;
30.  
31. implementation
32.  
33. procedure TDynCharArray.ReallocPtr(aNewLen: SizeInt);
34. var
35.   NewPtr: PAnsiChar;
36.   OldLen: SizeInt;
37. begin
38.   NewPtr := System.GetMem(aNewLen);
39.   OldLen := Length;
40.   if aNewLen > OldLen then
41.     begin
42.       System.Move(FItems^, NewPtr^, OldLen);
43.       System.FillChar(NewPtr[OldLen], (aNewLen - OldLen), 0);
44.     end
45.   else  //aNewLen < OldLen
46.     System.Move(FItems^, NewPtr^, aNewLen);
47.   System.FillChar(FItems^, OldLen , 0);
48.   System.FreeMem(FItems);
49.   FItems := NewPtr;
50. end;
51.  
52. procedure TDynCharArray.SetLen(aValue: SizeInt);
53. begin
54.   if aValue <> Length then
55.     begin
56.       if aValue = 0 then
57.         begin
58.           Clear;
59.           exit;
60.         end;
61.       if aValue > 0 then
62.         begin
63.           ReallocPtr(aValue);
64.           FLength := aValue;
65.         end
66.       else
67.         raise EInvalidOpException.Create('Can not accept negative length value');
68.     end;
69. end;
70.  
71. function TDynCharArray.GetItem(aIndex: SizeInt): AnsiChar;
72. begin
73.   if SizeUInt(aIndex) < SizeUInt(Length) then
74.     Result := FItems[aIndex]
75.   else
76.     raise EArgumentOutOfRangeException.CreateFmt('Index out of bounds(%d)', [aIndex]);
77. end;
78.  
79. procedure TDynCharArray.SetItem(aIndex: SizeInt; aValue: AnsiChar);
80. begin
81.   if SizeUInt(aIndex) < SizeUInt(Length) then
82.     FItems[aIndex] := aValue
83.   else
84.     raise EArgumentOutOfRangeException.CreateFmt('Index out of bounds(%d)', [aIndex]);
85. end;
86.  
87. class operator TDynCharArray.Initialize(var a: TDynCharArray);
88. begin
89.   a.FItems := nil;
90.   a.FLength := 0;
91. end;
92.  
93. class operator TDynCharArray.Finalize(var a: TDynCharArray);
94. begin
95.   a.Clear;
96. end;
97.  
98. class operator TDynCharArray.Copy(constref aSrc: TDynCharArray; var aDst: TDynCharArray);
99. begin
100.   if @aSrc <> @aDst then
101.     begin
102.       aDst.Clear;
103.       if aSrc.Length <> 0 then
104.         begin
105.           aDst.Length := aSrc.Length;
106.           System.Move(aSrc.FItems^, aDst.FItems^, aSrc.Length);
107.         end;
108.     end;
109. end;
110.  
111. class operator TDynCharArray.AddRef(var a: TDynCharArray);
112. var
113.   OldPtr: PAnsiChar;
114. begin
115.   if a.Length <> 0 then
116.     begin
117.       OldPtr := a.FItems;
118.       a.FItems := System.GetMem(a.Length);
119.       System.Move(OldPtr^, a.FItems^, a.Length);
120.     end;
121. end;
122.  
123. procedure TDynCharArray.Clear;
124. begin
125.   if Length <> 0 then
126.     begin
127.       System.FillChar(FItems^, Length, 0);
128.       FreeMem(FItems);
129.       FItems := nil;
130.       FLength := 0;
131.     end;
132. end;
133.  
134. end.
135.  

[MarkMLl]

If you want a data type that cleans up when it goes out of scope, why not just create one?
For example:

Somebody who's aware of the problem can far more easily preallocate a string of adequate length.

MarkMLl

[lainz]

Rust has an evangelism strike force. Pascal has not.

Someone will surely correct me if I am wrong: Pascal records are stack-based, classes are heap-based, objects default to stack but can be heap-based. Dunno about advanced records. Rust structs default to stack but can be heap-based. Are Rust structs directly equivalent to Pascal advanced records?

In terms of language features, most of the newer languages like Rust, Swift, Kotlin etc support nullable or optional types. Such types are supposed to help deal with the null reference, which inventor Tony Hoare has called his billion dollar mistake.

Indeed, too much YouTube videos to start with.

I think you're right about stack and heap.

About Nullable types, FPC has them as well in Trunk. The thing is for example to work with SQL queries that can return null, or using null as an expected value.

[lainz]

... but the memory- and this includes strings which have been used for passwords etc.- is not erased/blanked/wiped/zeroed/randomised...

Does Rust do that sort of thing?
And seems like Rust has managed to outperform C++ in syntax ugliness?

For the first question I don't know, what I wrote is what I've understood about the subject only reading their guide.

About ugliness, yes, maybe 

[lainz]

Put another way, people who say Rust is good are basically praising Pascal-like functionality which they perceive as superior to C-like functionality.

- The memory is erased as well in FPC, when the functions ends, that is what I understand, so no difference.

Not quite. By and large FPC makes variables inaccessible when they go out of scope, but the memory- and this includes strings which have been used for passwords etc.- is not erased/blanked/wiped/zeroed/randomised.

MarkMLl

Indeed, for that I've opened this thread. I noticed they're doing *almost* the same 

[dbannon]

OK, both those approaches would work but we won't win any "gee, thats better than rust" competitions that way I am afraid.

Generally, when I want to store some text, is in an ANSIString, I don't want to build new type and preallocating and remembering to overwrite at the end of a method (and any incidental exits) is just too hard (sits with thumb in mouth and sulks).

But by telling ANSIString that it is its responsibility to clean up when necessary sounds attractive.  That 'telling' happens right at the start of the method, but gets acted on whenever necessary. After all, ANSIString already has some clean up code already. But I'd hate to waste the time overwriting every data structure just for the very occasional time its needed, as rust does.

(No, I am not planning to put in a bug report, just, perhaps, demonstrating how easily we could match Rust if we thought it worthwhile !)

Davo

[pathfinder]

Why Rust when there is already Ada/SPARK?

[MarkMLl]

But by telling ANSIString that it is its responsibility to clean up when necessary sounds attractive.  That 'telling' happens right at the start of the method, but gets acted on whenever necessary. After all, ANSIString already has some clean up code already. But I'd hate to waste the time overwriting every data structure just for the very occasional time its needed, as rust does.

I think that when this was debated on the ML years ago attributes such as codepages were still a glimmer in the developers' eyes. I agree that something like that would be a step forwards.

MarkMLl

[MarkMLl]

Why Rust when there is already Ada/SPARK?

Never heard of it.

OK, every damnfool has heard of Ada, even if he insists on spelling it as ADA. But the point is that there are a lot of Rust evangelists at large, and there are a lot of Pascal evangelists in here, and some vanishingly small number elsewhere who believe that Ada and other early ALGOL derivatives remain relevant, so the question is either

* How can Pascal evangelists promote it against RUST?

or (to a more limited extent)

* Does Rust provide a viable alternative to Pascal?

If Ada/SPARK is at all relevant to either of those, then I suggest that you provide your own "compare and contrast", possibly in a separate thread, like OP did in this one.

MarkMLl