Is my love for Rust justified?

[Abmvk]

In my topic about my fear of C++, Rust came up, and someone suggested a topic “Is my fear of Rust justified”-topic in “Other programming languages”.

My first feelings for Rust are love, not fear, so I wanted to start that topic with a different title, and here it is.

I have no question at this moment, so anything Rust love/fear-related is on topic

[ame]

Ah, the zeal of the newly converted.

[Gavinmc42]

Learn as many languages as you can, then just use the one that best suits your application.
Or only make applications that suits the language you love.

I suspect those who "love" C++ are getting paid lots of money to write in it.

Rust does seem to be wining over Go and the fact that Linus approves is extra brownie points for Rust.
I check in on the Redox OS crowd to see their progress every 6 months or so.
Waiting for it to run on Pi's

Time, Cost, Quality, the project triangle.
For me that is Pi SBC's and Ultibo, it is a solution that meets all three criteria, for my apps.

I never got into Rust because I had trouble using Cargo behinds firewalls.
Been meaning to try it again but less time these days.

[jahboater]

Waiting for it to run on Pi's

It does run on Pi's
(at least it runs on my 8GB Pi4 running the 64-bit Raspberry Pi OS).

[jahboater]

For amusement, "hello world" program performance statistics for some languages ....

Assembler instructions: 8
Executable size 376 (1 block of 4096 bytes)

C instructions: 150,708
Executable size 6,120 (2 blocks of 4096 bytes)

Fortran instructions: 238,861
Executable size 6,152 (2 blocks of 4096 bytes)

Rust instructions: 365,528
Executable size 256,176 (63 blocks of 4096 bytes)

D instructions: 936,213
Executable size 1,246,936 (305 blocks of 4096 bytes)

Python instructions: 33,787,991
Interpreter size 23,468,144 (5730 blocks of 4096 bytes)

[Gavinmc42]

It does run on Pi's
(at least it runs on my 8GB Pi4 running the 64-bit Raspberry Pi OS).

Redox OS is not Rust on Linux, it is a Nix type OS written in Rust.

I think Rust and D are both using Run Time Libs, in C++ it is called the STL - Standard Library?
The Hello World kernel.img example for Ultibo is 823.2KB but it has no need to run on Linux.
The Free Pascal hello world that runs on Pi OS is 455.9KB.

Hello in Ada on Pi OS is 28.6KB, which is one reason I am learning it now.

Not sure what new language has no need for a big library runtime.

[Abmvk]

Ah, the zeal of the newly converted.

Guilty as charged

[ame]

Ah, the zeal of the newly converted.

Guilty as charged

You know it will never love you back.

[Heater]

I think Rust and D are both using Run Time Libs, in C++ it is called the STL - Standard Library?

Like C and C++, Rust does not need any run time libs. Of course there is code to get Rust started, setting up the stack, initialising globals, etc and run main() but no more than C has.

Like C and C++ there is a standard library containing useful things, like the ability to print, access the file system etc. Like C and C++, Rust programs do not need to include the standard library, as for example when building programs for microcontrollers. Rust code can be made as small as C code, it can run on 8 bit AVR microcontrollers for example.

Not sure about D, I understand it uses garbage collection and hence needs an actual run-time to take care of that.

[bensimmo]

With the likes of Linux as mentioned and also Microsoft/Windows incorporating Rust https://www.theregister.com/2023/04/27/ ... ndows_rust for its code, it probably is justified and now developers can write programs (apps) for it too https://learn.microsoft.com/en-us/windo ... or-windows


Why do you love it?



I like it as the banter between two of my students, one who decided to learn Rust vs one who uses LUA a lot, is amusing.

[Abmvk]

Ah, the zeal of the newly converted.

Guilty as charged

You know it will never love you back.

I am a romantic in the style of Goethe

[jahboater]

My first feelings for Rust are love, not fear, so I wanted to start that topic with a different title, and here it is.

I have no question at this moment, so anything Rust love/fear-related is on topic

I have to say, that it takes more than a hello, world program to make me "love" a language.

Decades of experience, when each time the language choice occurs, the go-to language that I know for certain will "get the job done", does lead to fondness for that language.

Also, after all that time, I know that language xxx is likely to be a viable choice in the future too.

[ejolson]

I think Rust and D are both using Run Time Libs, in C++ it is called the STL - Standard Library?

Like C and C++, Rust does not need any run time libs. Of course there is code to get Rust started, setting up the stack, initialising globals, etc and run main() but no more than C has.

Like C and C++ there is a standard library containing useful things, like the ability to print, access the file system etc. Like C and C++, Rust programs do not need to include the standard library, as for example when building programs for microcontrollers. Rust code can be made as small as C code, it can run on 8 bit AVR microcontrollers for example.

Not sure about D, I understand it uses garbage collection and hence needs an actual run-time to take care of that.

For the UTF-8 checking program compiled on a Raspberry Pi I get

Code: Select all

$ ldd u8scan
    linux-vdso.so.1 (0x0000007faf8af000)
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x0000007faf7d0000)
    libc.so.6 => /usr/lib/libc.so.6 (0x0000007faf620000)
    /lib/ld-linux-aarch64.so.1 => /usr/lib64/ld-linux-aarch64.so.1 (0x0000007faf872000)

which implies that the binary links to four different libraries at run time.

Is there a way to specify static linkage?

[Heater]

I have never tried it but apparently static linking Rust programs is possible: http://zderadicka.eu/static-build-of-rust-executables/

[Abmvk]

My first feelings for Rust are love, not fear, so I wanted to start that topic with a different title, and here it is.

I have no question at this moment, so anything Rust love/fear-related is on topic

I have to say, that it takes more than a hello, world program to make me "love" a language.

I would hope so. And believe it or not, but I am not an idiot either

[hippy]

For amusement ...

Python instructions: 33,787,991
Interpreter size 23,468,144 (5730 blocks of 4096 bytes)

Looks to be closer to 5MB on my Bullseye system ...

Code: Select all

pi@Pi4B:~ $ ls -l /usr/bin/python3.9
-rwxr-xr-x 1 root root 4703672 Mar 12  2021 /usr/bin/python3.9

Of course we should add in all run-time libraries used by executables in other languages and add in the size of the compilers to have a level playing field

[jahboater]

For amusement ...

Python instructions: 33,787,991
Interpreter size 23,468,144 (5730 blocks of 4096 bytes)

Looks to be closer to 5MB on my Bullseye system ...

Code: Select all

pi@Pi4B:~ $ ls -l /usr/bin/python3.9
-rwxr-xr-x 1 root root 4703672 Mar 12  2021 /usr/bin/python3.9

Of course we should add in all run-time libraries used by executables in other languages and add in the size of the compilers to have a level playing field

Interesting, I also see 5MB with ls -l.
But:

Code: Select all

$ filefrag -v /usr/bin/python
Filesystem type is: ef53
File size of /usr/bin/python is 23468144 (5730 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..    2047:    3180544..   3182591:   2048:            
   1:     2048..    4095:    1726464..   1728511:   2048:    3182592:
   2:     4096..    5729:    1654784..   1656417:   1634:    1728512: last,eof
/usr/bin/python: 3 extents found

Of course we should add in all run-time libraries used by executables in other languages and add in the size of the compilers to have a level playing

I don't think the size of the compiler matters. Every time you run a C/D/Fortran/Rust program, the compiler doesn't have to be loaded into memory.
But for Python of course, the interpreter must be loaded in memory every time the program runs.
What matters is the size of the executable, and assembler wins!

There is no run-time library for assembler by the way, the write and exit system calls are done directly with svc instructions.

Interestingly, programs written in Rust, D, Fortran, and Python all use the C run-time library.

[hippy]

I don't think the size of the compiler matters.

It does if one is comparing an executable which doesn't include a compiler with something like Python which does.

The root problem is it's comparing apples with oranges, is using an ill-defined measure of 'executable size'. I would have said the executable size of a Python program would be whatever size '.pyc' file Python would create if instructed to do that, '.mpy' file for MicroPython.

If we add Java to the mix - do we measure the size of the '.class', '.jar' or '.apk' file, or do we add in the size of the JVM as is effectively being done with Python ?

Size of C or C++ executable for a Pico is an interesting one, and I would say a useful measure as such an executable must include everything it needs to run. It also allows a more level playing field comparison with Python and anything else as we would be comparing UF2 content in all cases.

For a "Hello World" program, for MicroPython the UF2 will contain a 64 byte executable plus an interpreter of about 320KB.

For C the run-time libraries from Pico SDK are compiled and linked to include only what's needed so the equivalent would be about 8KB.

If one could link against a pre-compiled Pico SDK blob I would assume that would be somewhere between the two. That would probably be the level playing field comparison with MicroPython.

My C++ "Hello World", using only the Pico SDK libraries it needs, comes in at a whopping 280KB, not far short of MicroPython which does a whole lot more. I am not however a C++ programmer, I just grabbed the standard "Hello World" example from the net, so it probably could be made smaller.

[hippy]

I have to say, that it takes more than a hello, world program to make me "love" a language.

But it can be enough to have one decide to hate a language, or discount it as something that isn't worth the aggravation or perseverance of learning it.

The "fn" and "println!" of a Rust "Hello World" was enough to have me thinking it's the same old thing done a different way for the sake of being different which put me off from the start. I find it bad enough remembering it's "print" on one and "printf" on another when switching languages and I don't need another which is different again.

I am sure Rust does have attributes that are useful to have but I haven't been convinced it has anything I need which makes learning it worthwhile. Maybe I will consider it the perfect solution in the future but not now, not for me.

That's not to say I have any problem with anyone who chooses Rust as their preferred language. It's always a good thing to love the language one is using, no matter what that is.

[jalih]

I don't think the size of the compiler matters. Every time you run a C/D/Fortran/Rust program, the compiler doesn't have to be loaded into memory.
But for Python of course, the interpreter must be loaded in memory every time the program runs.
What matters is the size of the executable, and assembler wins.

I see it kind of pointless to measure just the executable size and speed. Apart from those two there is a very little reason to use C for anything.

[jahboater]

I see it kind of pointless to measure just the executable size and speed. Apart from those two there is a very little reason to use C for anything.

Well there are other things such as portability, stability/longevity, wide hardware support, wide compiler support, huge number of developers familiar with it, strong ISO standards, proven usage for serious projects (such as OS's etc), mature standard library (that the other languages all seem to use).

There are reasons why there is such a large amount of C code around (more than half the worlds software), and according to TIOBE anyway, it hovers around 1st and 2nd place in language popularity even after 50 years ....

All these developers cannot have made the wrong choice ?

And really, executable size and speed, are in fact important for many projects.

[jahboater]

The root problem is it's comparing apples with oranges, is using an ill-defined measure of 'executable size'. I would have said the executable size of a Python program would be whatever size '.pyc' file Python would create if instructed to do that, '.mpy' file for MicroPython.

I just define it as "what needs to be loaded into memory for the program to run". For C, it is the 6KB executable only (the library functions are only loaded as needed - called lazy loading). For common Python usage, it is the Python interpreter and the Python source file.
For Rust it includes its statically linked run-time library which makes the executable so large.

I tried your suggestion about the .pyc file for a better comparison.
The file created is tiny (170 bytes), but do I still need to invoke /usr/bin/python to run it? or can it be made into a standalone executable?

[jahboater]

But it can be enough to have one decide to hate a language, or discount it as something that isn't worth the aggravation or perseverance of learning it.

How about looking at the code produced (if efficiency is of interest) ?
For Rust, add "--emit asm" and it will produce an xxx.s file.
For C add "-S -o xxx.s" (also -fverbose-asm for included source code).

I am sure Rust does have attributes that are useful to have but I haven't been convinced it has anything I need which makes learning it worthwhile. Maybe I will consider it the perfect solution in the future but not now, not for me.

Yes, same here.
I purchased the book which is quite large. Rust seems to have grown.

That's not to say I have any problem with anyone who chooses Rust as their preferred language. It's always a good thing to love the language one is using, no matter what that is.

+1

Back to performance comparisons, looking at ldd for the hello world program we have (removing the two linux ones):

Rust ...
libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000007fa2056000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007fa1ee1000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007fa1eb0000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007fa1e9c000)

C ...
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007fa7838000)

Yet Hello,world does not use threads or libdl, so why does Rust load them? (and I suspect the C library includes threads anyway?)
I don't think GCC supports Rust yet (its coming), so why is libgcc being linked?
As for the C library which is considered so insecure by Rust purists, why load that?

[hippy]

I tried your suggestion about the .pyc file for a better comparison.
The file created is tiny (170 bytes), but do I still need to invoke /usr/bin/python to run it? or can it be made into a standalone executable?

That is an interesting question. One would normally use Python to execute it, requiring the entire super-sized enchilada, but it would be possible to build a smaller interpreter which only handles the byte codes the '.pyc' uses, and it should be possible to convert that byte code into C or other language and compile that to get an actual native executable.

MicroPython does have options to build firmware which is just an interpreter without the REPL, without the complier, but I've not adventured in that direction.

It has always been possible to convert Python into C and compile that but that usually brings in a lot of overhead. Python being typeless and dynamic introduces overhead which typed languages won't have but there have been efforts to apply type and that can make things more efficient, require less code to support. MicroPython itself is capable of producing both a more optimised bytecode and native Thumb32 code and this looks interesting for the desktop -

https://thenewstack.io/mit-created-comp ... ython-code

But it can be enough to have one decide to hate a language, or discount it as something that isn't worth the aggravation or perseverance of learning it.

How about looking at the code produced (if efficiency is of interest) ?

Possibly. If there really were compelling efficiency gains it might justify more than a cursory assessment, but I don't see that being claimed as a reason to use Rust. None of the potential gains from using Rust seem to outweigh having to learn it for me.

I tried TinyGo because that was said to produce quite small self-contained executables but walked away when it took 40 seconds to compile a simple "Hello World". Again I couldn't see that the gains outweighed the effort.

I wasn't impressed by Python when I first looked at it, and there are still things I don't like, wish were different. The indentation being significant took a little getting used to, and many people are unable to get beyond that, but I had a need for a replacement to what I had been using, it appeared it would be a good fit to the things I usually did, and the potential gains seemed to outweigh the effort, so I persevered. I can't say I love Python but I do believe it was the right choice for me.

One thing I would say for Python is that the learning curve to being able to produce useful production code wasn't steep. I may be wrong but it seems the learning curve for Rust to get to the same level is steeper.

[ejolson]

As for the C library which is considered so insecure by Rust purists, why load that?

From what I can tell Rust aims to be an improved version of C while C++ aims to be a version of C with more features. The reason this can be possible is that not all features are improvements nor are all improvements features.

For an improved version of C one of the requirements is interoperability. Rust uses the same calling conventions as C precisely so you can link Rust with well established C libraries. Thus, it's not surprising to see glibc among others in the dynamic dependency list.

According to Fido, if an established C library has been heavily scrutinized and tested over time, it is likely more secure than the equivalent functionality written last week in Rust. At the same time anything written last week in C is likely less secure than the same thing written last week in Rust. The attraction, then, of Rust is to help create new code that is free of serious bugs while preserving a legacy of proven C code and libraries.

Although the above sounds plausible, it should be noted that Fido is a dog who prefers to program in Basic.