The Case for Rust (in the base system)

T-Aoki said:
Interesting language. lang/numbat.

Not sure how actually usable it is (as I'm not yet actually studied it), but it seems to be kinda "safe" language. It seems to free us from mangling units like km vs mile, kg vs lb, deg vs rad.

Unrelated with this thread? No, no! It's written in Rust (unfortunately for me to understand the implementation).
Click to expand...
For many scientific computations, that would be really nice. For an inconvenient version, there are class libraries: I know one for Python, and I remember seeing one for C++ decades ago, when I was still a professional physicist. The problem here is that without language (compiler or parser) support for literals with units, the syntax gets awful. Here is what code should look like:
Code: 
d = 3m  # I'm omitting the type declaration for a didactic example
x = 12mm
t = 2s
v = d / t  # The units of v should now be 1.5 m/s
r = d / x  # The result should be 25 with no units
rrr = d + t  # This should assert
but the parser would barf (*) on literals such as "3m" and "2s". So you end up having to write it like this:
Code: 
d = Quantity(3, "m")
x = Quantity(12, "mm")
t = Quantity(2, "s")
Quantity v = d / t  # The result will be Quantity(1.5, "m/s")
r = d / x  # Is the type of r an int, a float, or Quantity(25, "") ?

Sadly, the number of people who really need this is small, so it's probably not worth it to add support to one of the major languages.

Footnote: That means "the parser would not be able to process ..."
 
T-Aoki said:
Interesting language. lang/numbat.

Not sure how actually usable it is (as I'm not yet actually studied it), but it seems to be kinda "safe" language. It seems to free us from mangling units like km vs mile, kg vs lb, deg vs rad.

Unrelated with this thread? No, no! It's written in Rust (unfortunately for me to understand the implementation).
Click to expand...

No reason to invent a new language.

Safely dealing with scientific units can be done (at compile time) in Common Lisp:

medium.com

Safely dealing with scientific units of variables at compile time (pt 3 of compile-time computing)

There is constant debate whether to include units in variable and field names such as in “length-in-meters”.
medium.com medium.com
 
cracauer@ said:
No reason to invent a new language.

Safely dealing with scientific units can be done (at compile time) in Common Lisp:

medium.com

Safely dealing with scientific units of variables at compile time (pt 3 of compile-time computing)

There is constant debate whether to include units in variable and field names such as in “length-in-meters”.
medium.com medium.com
Click to expand...
Interesting!
But the history of programming language (at least on their early ages) was to create easy-to-code languages per their use-cases, for example, FORTRAN for number crunchers, COBOL for business computing, C for writing Unix, instead of assembly languages / binary codes for each processors.

Recently I consider C without libraries (purely as language specs) as an abstracted assembly language, so compiling other languages into C is quite natural, if standard (and optional) libraries are NOT forced but calling convention per CPU. If the runtime libraries for specific languages like Rust are NOT conflict with libc and crt*.o, resulted C codes would be inter-operable with current C codes.
 
cracauer@ said:
Fwiw C++ also gained some capability of writing down literals with their units:
Click to expand...
That seems useful, and might make it possible to create a set of classes for "numbers with units" that works conveniently. I should look whether someone has done it ... but then, I'm not planning to do any programming in C++ for fun. After all, this is the Rust thread. I've actually abandoned my home rust project; it was just going too slowly, and there were more urgent projects (which either used Python, or used a tractor and shovels).
 
This is my opinion. radians is a clever may to change degrees so they can be used as arguments in mathematical functions, like sin(x). the posts before are also good ways to see then.
 
C++ actually gets better now with ranges, and all the stuff the standard library can handle for you.
I am not to worried anymore, and see Rust as a preference rather than as a complete replacement.
For memory management use smart pointers, and RAII to be on the safe site.
Some days ago I updated my C++ knowledge, and got such tips recommended.
 
Sometimes I wonder if this thread is just a dumping ground for comments on C/C++/Rust. I just don't see it as a 'conversation' any longer, but more of a reflection of what happens when people have nothing else to talk about.
 
SDK Chan said:
For memory management use smart pointers, and RAII to be on the safe site.
Some days ago I updated my C++ knowledge, and got such tips recommended.
Click to expand...
RAII solves perhaps 1% of the memory management problem in C++, and eliminates mostly just the "use null pointers and uninitialized memory by mistake" problems. And smart pointers (usually referring to ref-counting pointers that auto-delete the underlying storage when the last reference drops) also only solve a part of the problem, since they can't deal with data structures that form circular references, which exist all over the real world.

My way of summing up the problems with C++: There are whole textbooks about the semantics of move, when you call a function with a pointer.
 
astyle said:
Sometimes I wonder if this thread is just a dumping ground for comments on C/C++/Rust. I just don't see it as a 'conversation' any longer, but more of a reflection of what happens when people have nothing else to talk about
Click to expand...

Please don't start war again 😂😂
Why we should speak about what we not need?
 
In a sudo replacement of all things: And not just priv escalation, partial reading of passwords.

Code: 
Package        : rust-sudo-rs
CVE ID         : not yet available
  
Two security issues were discovered in sudo-rs, a Rust-based implemention
of sudo (and su), which could result in the local disclosure of partially
typed passwords or an authentication bypass in some targetpw/rootpw
configurations.
 
And maybe over-reliance to "we are bug proof my design" is at play here, also. Has anyone seen the amount of work it takes to build a good crypt library that does not provide an attack surface for timing attacks? You might be better off here with switching off the optimizer of your macro assembler, ahem, C compiler. And who knows what some compilers do behind the surface? Is the machine code audited that it does what you intend? I just did that for a small function. Sometimes, you need to be sure.
 
If code generator into Rust (or any other language) from, i.e., LLVM IR just like generating native binary codes is possible, rewrite would be realistic.

And by prohibiting UNSAFE blocks, errored out source codes can be considered mutually unsafe, means, Rust is not for the code or real rewrite (refactor) is mandatory to switch to Rust.
 
There's something that has been bouncing around in my head for a while, and I think I'm ready to put it into words.

Whenever your ead people knowledgeable on both c and rust, the claims and comparisons seem to be realtively (relatively) tame. Marginal advantage in compile times here, easier logical cohesion there. A bit more, a bit less. But there seems to be a gigantic and very motivated advocacy constantly going on around rust, giving the impression of much grander advantages being claimed, drastic differences. Night and day.

This is what has been tinkling in the back of my head. Sure, memory safety is a difficult task for humanpersons. But maybe it is actually even far more of a stumbling block for autogenerated programs. Maybe a person's intuition, a person's ability to grasp disconnected and incohate pieces and logic them into a thought bundle, still has an important edge here. At least at scale.

When I see this level of advocacy, and notice that the advocates tend to either be recent graduates or spokespeople for mega institutions (governments, Forbes companies), my first thought is that there is some big capital seeing an opening somewhere.

When we add the fact that Rust is so different from previous languages and is unlikely to pull in too many programmers, is it not possible that the reason for the push is that the ideal AI programming language is being sought? That the difference between generating a program that can program X in c and one that can program it in rust is in the hundreds of millions of dollars?

Safety rails of marginal utility for humans, but of critical advantage for highly advanced abacuses. Clearly defined limits a priori.
 
You must log in or register to reply here.
Back
Top