Comparing Pascal and Rust

[pathfinder]

then I suggest that you provide your own "compare and contrast", possibly in a separate thread, like OP did in this one.

I would suggest you understand what a rhetorical statement means. 

Further, I would suggest with the tone you carry that it isn't beneficial to Lazarus/FPC with the already tiny market it has.  If I was looking to possibly use this product versus, say, Racket, I'd go with the community that doesn't have confrontational members.  Like Racket.

Anyway, thanks for providing me with a last post and a reason to go with something else.

[Warfley]

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.

Rust is more typesafe because the access is controlled on a finer granularity. For example, let's say you want to give a record read access to another record in pascal

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

1. type TTestRec = record
2.   SomeReference: PInteger;
3. end;
4.  
5. function createRec(constref reference: Integer): TTestRec;
6. begin
7.   Result := @reference; // at this point the information that this is a constant reference is lost, no way to get that information into the record
8. end;
9.  
10. var
11.   i: Integer;
12.   test: TTestRec;
13. begin
14.   i := 42;
15.   test := createRec(i);
16.   test.SomeReference := 32; // i just overwrote something that should be constant
17. end;
18.  

Compare this to rust:

Code: C  [Select][+][-]

1. struct SomeStruct<'a> {
2.    SomeRef: &'a i32,
3. }
4.  
5. fn createStruct(reference: &i32) -> SomeStruct {
6.     return SomeStruct {
7.         SomeRef: reference
8.     };
9. }
10.  
11. fn main() {
12.     let i = 42;
13.     let test = createStruct(&i);
14.     *test.SomeRef = 32; // this throws a compiler error, because the reference is not mutable
15. }
16.  

The problem here is that the mutability information can not propagate in pascal through anything but function parameter. So unless we all start going fully functional now, we will loose this information eventually.
This means that no matter how smart the FPC is, it simply can not provide the type safety rust provides, because the language simply can not provide for the information on the level that rust does.

Pascal does not have a concept of immuatble memory locations. But you don't even need to go so far to rust to see it, C for instance does also have it:

Code: C  [Select][+][-]

1. struct SomeStruct {
2.   int const *SomeRef;
3. }
4.  
5. SomeStruct createStruct(int const *ref) {
6.   return {
7.     SomeRef: ref
8.   };
9. }
10.  
11. int main() {
12.   int i = 42;
13.   SomeStruct test = createStruct(&i);
14.   *(test.i) = 32; // compiler error
15. }

But thats not where rusts safety ends, you might have noticed the <'a> in the struct definitionm this is a lifetime information of that struct. Rust tracks the lifetime information of all references on a language level, so if we modify the main function a little bit:

Code: C  [Select][+][-]

1. fn main() {
2.     let test: SomeStruct;
3.     {  // create a scope, all local variables defined within here will be destroyed afterwards
4.         let i = 42;
5.         test = createStruct(&i);
6.     } // the scope ends, i is destroyed, test.SomeRef is a dangling pointer
7.     println!("{}", *test.SomeRef); // error, as rust notices the lifetime disparity
8. }

The rust compiler notices that the lifetime of the struct and the one of the reference don't align and throws an error
This completely solves the problems of dangling pointers. But this also requires the user to provide additional lifetime information at a granular level, which requires special syntactical constructs.

The next thing is that rust tracks the number of references, it ensures that there is always only one mutable access:

Code: C  [Select][+][-]

1. fn main() {
2.     let mut i = 42;
3.     let test1 = createStruct(&mut i);
4.     let test2 = createStruct(&mut i); // throws error because there was already one mutable reference
5.     println!("{}", *test1.SomeRef);
6.     println!("{}", *test2.SomeRef);
7. }

Also while a reference is active (in rust speak the variable is borrowed), it can not be changed:

Code: C  [Select][+][-]

1. fn main() {
2.     let mut i = 42;
3.     let test1 = createStruct(&i);
4.     i = 32; // throws an error because test1 borrows it
5.     println!("{}", *test1.SomeRef);
6. }

This makes use-after-free and double-free impossible, but this is only possible due to precise tracking of the mutability and lifetime information. It is mathematically impossible to ensure this during compiletime in Pascal, this is only possible in Rust because the language is restricted through the enforcement of mutability and lifetimes which makes this a computable problem.

So about your last statement:

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.

The answer is simply no. Pascal has neither the capabilities to restrict mutability nor lifetime on a syntactic level. Therefore the features that the Rust compiler provides are impossible to do on Pascal code.


It should also be noted that the syntactical makeup of a language changes the behavior of the developer. In for example C, everything is mutable unless defined otherwise, in rust it is the other way around. This leads to C developers having more things mutable than strictly being neccessary, simply because the developer did not bother to add the const modifier. By doing it the other way around, rust ensures that the developer only makes the things mutable that are neccessary to have mutable.

[MarkMLl]

Look, I really don't see what your problem is here.

Sure, Pascal is rapidly heading for "niche" if not "boutique", because it is /perceived/ as being an obsolete, inflexible language that hasn't been touched for 40 years.

Rust gets an enormous amount of positive press, maybe deservedly and maybe not. Comparing and contrasting the two is very useful irrespective of the angle.

Ada is /perceived/ as being oversize, inflexible and moribund except possibly in the context of large-project maintenance in defense contractors.

I stress /perceived/ in all three cases there, because just about everybody here knows that at least in the case of Pascal and Ada things are much more complex.

Now if you have something useful to say that either contributes to the Rust vs Pascal debate or positions Ada as being relevant to it we're all most interested to see your contribution.

MarkMLl

[MarkMLl]

The answer is simply no. Pascal has neither the capabilities to restrict mutability nor lifetime on a syntactic level. Therefore the features that the Rust compiler provides are impossible to do on Pascal code.

Thanks very much for that, very interesting. I must say that OP's point about very strict typing was also something I consider attractive.

Thinking back to various bare metal stuff I've done in the past, some of the mutability aspect could probably be handled by changing protection attributes on different areas of memory... in some ways that would be finer-grained but it would also be much more work.

Noting the (non-)mutability aspect of functional languages, but when did this sort of thing enter the mainstream? With a nod to @Pathfinder (if he's still around) did Ada or any other self-professed "safe" language implement that sort of thing?

MarkMLl

[lainz]

So about your last statement:

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.

The answer is simply no. Pascal has neither the capabilities to restrict mutability nor lifetime on a syntactic level. Therefore the features that the Rust compiler provides are impossible to do on Pascal code.

Indeed, this is the thing on my comparison, that FPC can't do. But the things in common are say the advanced records, constants and references, well other things was proved that FPC can't (by default), like strings (on the heap) erasing (that can be added if someone does it) and that by default memory is a copy in FPC and not a single pointer at a time.

Is impossible actually, but it is impossible to implement as well?

[Warfley]

Noting the (non-)mutability aspect of functional languages, but when did this sort of thing enter the mainstream? With a nod to @Pathfinder (if he's still around) did Ada or any other self-professed "safe" language implement that sort of thing?

MarkMLl

I don't know which was the first language to have that, but it is a big thing in C, so it is already pretty old.

In C you have the concept of objects (this is the name that the C standard gives, has nothing to do with OOP) and each object can have certain modifiers. For example:

Code: C  [Select][+][-]

1. int i; // this is an int object
2. int *i; // this is a pointer object pointing to an int object
3. int const i; // this is an int object with a const modifier

These objects can be constructed sequentially, where each modifier modifies the type to the left of it.
For example

Code: C  [Select][+][-]

1. int const * volatile * const i

This is a constant pointer object, pointing to a volatile pointer object pointing to a constant int object.
Note that a modifier in front of a definition only effects the first object in the chain:

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

1. const int *i;
2. // is the same as
3. int const *i;
4. // not
5. int * const i;

Which is a pitfall where many beginners fall into because they assume the pointer is const, but in reality the value pointed to is const.

This allows for very granular access control, for example:

Code: C  [Select][+][-]

1. int * const i;

makes the pointer immutable, this could for example be used to make access to shared memory, which has a fixed location in memory, so you can't change the pointer, but you the int value behind that pointer is not modifyable:

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

1. i = &othervar; // compiler error, the pointer is const
2. *i = 42; // works fine

This can be put anywhere

Code: C  [Select][+][-]

1. struct Test {
2.   int const *i; // a pointer to a constant integer
3.   int * const p; // A constant pointer to a variable integer
4. }

I think that this is something that is really lacking in pascal. You can only have this form of access control in function parameters, and then there is only one layer:

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

1. procedure foo(constref param1: Integer; const param2: PInteger);

Here you have a pointer to a constant integer as well as a constant pointer to an integer. But you can't go deeper then that, and constref is rather new anyway, so for a long time we didn't even have that.
Also as I noted above this is not enforced, so:

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

1. procedure foo(constref param: Integer);
2. var test: PInteger;
3. begin
4.   test := @ param;
5.   test^ := 42; // I just changed a constant value, without a compiler error or warning
6. end;

In C this looks different:

Code: C  [Select][+][-]

1. void foo(int const *param) {
2.   int *test = param; // does not work
3.   int const *test2 = param; // only this works
4.   // workaround
5.   test = (int*)param;
6. }

So you can work around this, but this requires effort, so you need to be at least in some form conciously aware of what you are doing, and in C++ this is even more explicit:

Code: C  [Select][+][-]

1. int *test = const_cast<int *>(param);

Making it clear to everyone who reads it that you made a concious decision to remove the const here, which might be neccessary at times, but should require a good bit of explaination, as usually some things are const for a reason.

I really like this and miss that pascal does not have something comparable to this, as especially the possibility to return constant pointers would be great (e.g. give read access to a field of a class without having to worry that data will be changed)

[Warfley]

Indeed, this is the thing on my comparison, that FPC can't do. But the things in common are say the advanced records, constants and references, well other things was proved that FPC can't (by default), like strings (on the heap) erasing (that can be added if someone does it) and that by default memory is a copy in FPC and not a single pointer at a time.

Is impossible actually, but it is impossible to implement as well?

But your comparison completely misses the point why rust is the way it is and why it is so popular among the low level development community. The typesafety does not stem from advanced records or constants or references in particular, but the special way they are implemented. Sure both pascal and rust have andvanced records, so does C++ or C#, but the thing that makes rust advanced records special is the runtime tracking of the record and the members due to runtime information annotations (the <'a> in my example). Sure pascal has references, so does nearly any language, but the thing that is special about rust is the reference tracking and enforcement of maximum references which requires runtime information and fine grained mutability information. And yes there are constants in rust and pascal and again, C++, C#, Java, you name it, but the thing that is special about rust is the granularity of that information, that is completely lost in Pascal.

And by the term impossible I mean mathematically provable impossible (via rices theorem) in the current way the language is defined. It requires massive changes to the Pascal language syntax and semantic to make this possible. Basically to do this one would need to turn pascal into rust. Sure this is possible, but I don't think that it is quite so good of an idea to trying to mirror another language tail to foot, because if I wanted to have rust, I'd use rust not Rustlike pascal?

[lainz]

Thanks Warfley, as I said I don't know fully Rust so mi comparison can be wrong as well. That's the good part of the forum where others can know more than one.

Indeed about not using Pascal for everything. But maybe I don't have a target application for Rust yet so my comparison was biased in that point too. Not like I will do a system that needs to run so fast or so secure, that I only need to use records, ensure they are not changed and so on. Maybe any application can benefit from it, just I'm not fully aware of the concerns maybe.

Thanks for all the comments, learning from others all days is really good in this forum.

[Warfley]

A software that famously is transitioning to Rust is Firefox. This needs to be highly secure and really fast, which is why Rust is perfect.

But no, rust is not a language for every software, it does not even try to be. If you don't need the performance, but the safety, you are much better advised using a garbage collected language like Java, where all these memory problems are also solved by having a garbage collector. In Pascal you could use reference counted interfaces, if you are unsure about memory management.

Rust is a really specific language for a really specific niche. Low level high performance development. Operating Systems, Browsers, Simulators, etc.

But that said, some features could of course be considered for Pascal, Pascal does not need to go full rust, but something like the fine grained const modifiers as they are in C (as I mentioned above) could be a great addition to pascals type system (of course in a pascallian way and only as an opt in solution with a special mode switch).

[marcov]

A software that famously is transitioning to Rust is Firefox. This needs to be highly secure and really fast, which is why Rust is perfect.

It is why they designed it that way. Rust comes from the Mozilla foundation, the originator was a Mozilla employee.  So it would be pretty bad if it wasn't suitable ;-)

Anyway, alternate safe helpers would be possible, and a directive to switch to them for critical sections of code also seems possible. But if you would pass strings outside those areas, it would be dangerous again. That can be helped by having some runtime property attached to every string, but that is slowing for the bulk of applications that don't need it.

Thinking about it, my guess it would then only work if an application and the libraries it uses would be compiled with such switch, meaning you would need a special distribution of the compiler/libraries/lazarus etc.

[MarkMLl]

It is why they designed it that way. Rust comes from the Mozilla foundation, the originator was a Mozilla employee.  So it would be pretty bad if it wasn't suitable ;-)

But you ought to see some of the stuff that's emerged from places like IBM... not to mention MS et al. Remember in the late 80s when Bill Gates (at his most rapacious) said that in a few years absolutely everything would be written in Visual Basic?

Thinking about it, my guess it would then only work if an application and the libraries it uses would be compiled with such switch, meaning you would need a special distribution of the compiler/libraries/lazarus etc.

I'd already got there thinking about the string-wipe problem and system functions like ReadLn(). However, (a) would doing this properly in the RTL/FCL/LCL really introduce unacceptable overhead when compared with the performance lost in X11 and higher-level stuff? (b) having maximal checks enabled during development- even if aspects could be turned off for release- might still be viable.

MarkMLl

[marcov]

Thinking about it, my guess it would then only work if an application and the libraries it uses would be compiled with such switch, meaning you would need a special distribution of the compiler/libraries/lazarus etc.

I'd already got there thinking about the string-wipe problem and system functions like ReadLn(). However, (a) would doing this properly in the RTL/FCL/LCL really introduce unacceptable overhead when compared with the performance lost in X11 and higher-level stuff? (b) having maximal checks enabled during development- even if aspects could be turned off for release- might still be viable.

(a) FPC is used for other things than X11, including memory databases etc, iow not just GUI apps.
(b) It can be, but it simply needs a separate unit tree. But practical final delivery is still far in the distance. First somebody needs to work on it and proof its worth.
 

[PierceNg]

It should also be noted that the syntactical makeup of a language changes the behavior of the developer. In for example C, everything is mutable unless defined otherwise, in rust it is the other way around. This leads to C developers having more things mutable than strictly being neccessary, simply because the developer did not bother to add the const modifier. By doing it the other way around, rust ensures that the developer only makes the things mutable that are neccessary to have mutable.

Thanks for the illustrative writeup.

[circular]

But you ought to see some of the stuff that's emerged from places like IBM... not to mention MS et al. Remember in the late 80s when Bill Gates (at his most rapacious) said that in a few years absolutely everything would be written in Visual Basic?

I would be glad to have a link to that. 

About the subject of erasing a string, assigning a new value doesn't work. Though you can simply do:

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

1. password := GetThePassword();
2. ...
3. if password <> '' then
4. begin
5.   FillChar(password[1], length(password), 0); // erase the content
6.   password := ''; // erase the reference, so one cannot follow it to get the length of it
7. end;

[MarkMLl]

But you ought to see some of the stuff that's emerged from places like IBM... not to mention MS et al. Remember in the late 80s when Bill Gates (at his most rapacious) said that in a few years absolutely everything would be written in Visual Basic?

I would be glad to have a link to that. 

I think that predates links :-) My attention was drawn to it by an associate, and I suspect that- like just about everything else he thought he knew about computers- it had been in Byte.

MarkMLl