The Case for Rust (in the base system)

ralphbsz said:
and your code is likely to be lightyears faster.
Click to expand...
My inner Monk has the urge to slap you with a large trout.

As for evil stack voodoo, just check what alloca() can do. That is a huge problem.
The main problem with these languages and the checks is that they are based on the old model of compilation with object files as a product, or even assembly files. Languages like (object) pascal will also produce .unit files, containing a lot more information. FPC can inline functions from other units, without seeing the source code. Same for templates. It would be easy to add a "won't escape" attribute, so the compiler could at compile time check all called methods if something can escape (and maybe even where to). C/C++ don't do that. It can't.
 
ralphbsz said:
And in many cases, array bounds checking (and many similar checks, like refcounts) can be elided by the compiler. For example, if you write this code:
Code: 
int a[20];
for (int i=3; i<17; ++i)
    a[i] = ...;
the compiler doesn't have check that i is within range, because it's obvious. And even if it had to check (for example because the bounds 3 and 17 were passed in as arguments), common subexpression elimination might have moved the check before the loop, and it's a very fast register comparison. So trying to optimize by removing checks is nearly always false economy.
Click to expand...

But is there a real-world compiler that would insert array bounds checking normally and optimize it out in this case?

I suppose even a C compiler could be this smart even though C doesn't have array bounds checking. If you were to manually write a bounds check into the loop body the compiler could be smart enough to optimize that out as dead code. But to my knowledge no such compiler exist for this particular case where the array size is given in a stack allocation of the array.
 
cracauer@ said:
In Lisp you promise the compiler explicitly that a variable (or parts thereof) won't leak. If you made an untrue promise you get a hard to debug memory error.
Click to expand...
I thought at least some GC languages use the stack as a cache or "nursery" and move live objects from it at the time of GC. I think Chicken Scheme uses Henry Baker's "Cheney on the M.T.A." allocation scheme, where everything is allocated on the stack and when the stack runs out, all the live objects are copied out.
 
Some Rust versioning bashing:

RustLang’s Semantic Versioning Still Breaks Too Many Apps

"someone running a project based on these crates in the survey would experience a breaking change once every 10 days"

thenewstack.io

RustLang's Semantic Versioning Still Breaks Too Many Apps

In an environment of automated builds, incorrectly versioned packages build can wreak havoc, one Rust dev notes on the Changelog podcast.
thenewstack.io thenewstack.io
 
I'd like to suggest some easy reference points wether it is a good idea to add language X to base or kernel. We don't need to argue all the points again if that has already happened elsewhere.
  • Is the language used in embedded systems?
  • Is the language used in medical applications?
  • Is the language used in avionics?
I weant a kernel fit for all these points. I want a userland fit for all these points. And I don't want to argue the points already argued by these areas again and again.

I remember a rant from someone in the data visualization field that they can only do prototypes in JS because the dependency hell makes it near impossible to have reproduceable builds and don't ask about certification. But nobody would think about writing a kernel mode in JS, yes?
 
drhowarddrfine said:
There are 106 languages FreeBSD could be re-written with.



Nim! 107!!
Click to expand...
LOL

At OpenHack a few years ago (before the pandemic) some web developer kept needling me that FreeBSD needed to be rewritten in Java. Every time my reply was, "in your dreams." A bit of banter but still a funny story.

Funny story though.
 
Crivens said:
I'd like to suggest some easy reference points wether it is a good idea to add language X to base or kernel. We don't need to argue all the points again if that has already happened elsewhere.
  • Is the language used in embedded systems?
  • Is the language used in medical applications?
  • Is the language used in avionics?
I weant a kernel fit for all these points. I want a userland fit for all these points. And I don't want to argue the points already argued by these areas again and again.

I remember a rant from someone in the data visualization field that they can only do prototypes in JS because the dependency hell makes it near impossible to have reproduceable builds and don't ask about certification. But nobody would think about writing a kernel mode in JS, yes?
Click to expand...
Would need to add:
  • Is the language used in military systems?
  • Is the language used in nuclear power plant control system?
Not limited to Rust, introducing new languages into base could cause feasibility problem in the future.
The applications I added above mutually requires long term service period, usually over 20 (or even 50) years, both in stability in language spec and human resources.
If the language can surely survive for next 50 years, maybe it's worth trying.
 
cracauer@ said:
Some Rust versioning bashing:

RustLang’s Semantic Versioning Still Breaks Too Many Apps

"someone running a project based on these crates in the survey would experience a breaking change once every 10 days"

thenewstack.io

RustLang's Semantic Versioning Still Breaks Too Many Apps

In an environment of automated builds, incorrectly versioned packages build can wreak havoc, one Rust dev notes on the Changelog podcast.
thenewstack.io thenewstack.io
Click to expand...
Well, versioning scheme of ports seems to be better than SemVer.
SemVer doesn't seem to have epoch, for the time reverts are needed.
On poudriere or any builder/updating tools, missing epoch on reverts cause confusions. Would be so as SemVer.

And more important thing is that crates are not parts of Rust "language" itself. So would be better treated as different matter.
 
T-Aoki said:
Would need to add:
  • Is the language used in military systems?
  • Is the language used in nuclear power plant control system?
Click to expand...
You can skip military systems. First, they will most likely not give you all the facts (guess why I write that...). Second, they use things like kubernetes in airplaines, that removes some credibility points im my humble opinion.

One good indicator is the terms of insurance available, because those guys will nail your hide to the barn if something goes wrong. If you work unsafe, they will charge a lot more.
 
cracauer@ said:
Some Rust versioning bashing:

RustLang’s Semantic Versioning Still Breaks Too Many Apps

"someone running a project based on these crates in the survey would experience a breaking change once every 10 days"

thenewstack.io

RustLang's Semantic Versioning Still Breaks Too Many Apps

In an environment of automated builds, incorrectly versioned packages build can wreak havoc, one Rust dev notes on the Changelog podcast.
thenewstack.io thenewstack.io
Click to expand...
To be fair, this sort of thing happens in all languages. I dunno why we're so bad at versioning things.
 
cracauer@ said:
I wouldn't say C is broken, but it goes on my nerves. Particularly the lack of ability to have generic algorithms and data structures. At the same time C++ has IMHO gone off the deep end and sized itself (as in mental load size) out of competition with C++20. I didn't even look at C++23 yet. I guess I am a Rust programmer now?
Click to expand...
Then Zig would do the job.
 
Andrey Lanin said:
Sarcasm is clear, but I think that this is exactly what will be useful in C++, unlike many other things added in the last 10 years. ?
Click to expand...
To be fair, they were going to cram more random crap into the language anyway. At least this stuff is truely useful.

Agreed. The last time a real nod towards safety was made was probably TR1/c++0x with "blessed" smart pointers (yes, lets ignore auto_ptr). Sean Baxter (behind this) has clearly had to work hard to make progress with the standards comittee!

Can it work? Certainly more likely than rewriting everything in Rust.
 
I don't want to sound too pessimistic. I'm a not too active member of WG21 and mostly interested in SG32 (that's the ISO C++ commitee and the safety and security subgroup). I don't fancy Sean's chances for the moment. He's only just started participating in standardization. The main problem that I see is that he's a one man band with his own closed source C++ compiler (Circle). It's going to be a huge amount of work for him and getting the corporations and compiler vendors on board is going to be a mammoth task.

At the least I see this as something to aim for and possibly a subset will get spun off and included in the standard.
 
Paul Floyd said:
Click to expand...
This is an interesting paper, I will try to spend a little more time to digest it. Though one thing did stand out that made me chuckle:

To win, Java has to surpass Microsoft’s J++ in attractiveness to software developers. This means
better design better thought through, less prone to error, easier to debug, … and many other things.
Click to expand...

... or Sun could just sue Microsoft and *beat* J++ that way ;)

As for the proposal, I'm not entirely convinced by reproducible floating point ops. The maths is all slightly "wrong" at that point. I don't think different peoples slightly wrong maths need to match perfectly. It also cited "the games industry" as a big consumer of the proposal. At risk of trivialising it, honestly, much of it is just churning out wooden toys compared to expertly crafted furniture. Even -ffast-math is good enough for 99% of it.
 
Paul Floyd said:
How about this one?


At least it would be opt-in.

Then take a look at


"Linguistically legislated exact reproducibility is at best mere wishful thinking."

(Kahan got the Turing award for his work on floating point).

Even if they get the basic mathematical operators to work there are still differences in libc transcendental funcitons.
Click to expand...

If you want exact math you could use a language that does arbitrary length integers transparently and also transparently uses fractions (not floaing point) as a default result of integer division.

(both in Common Lisp)
 
Paul Floyd said:
Then take a look at


"Linguistically legislated exact reproducibility is at best mere wishful thinking."

(Kahan got the Turing award for his work on floating point).
Click to expand...
I read that a while ago. I thought most of his proposals were adopted by the JVM, but the only JSR I can find was withdrawn ?

Maybe some his suggestions were adopted in JDK 6?
stackoverflow.com

Does Java's floating point implementation still have the problems identified by Kahan?

I've read a few papers from Kahan tonight, and his famous rant against Java. Before I dive into the JVM spec, did anything change since the initial rant on this front? For example: setting round...
stackoverflow.com stackoverflow.com
 
Out of curiosity, is the question of Rust in the kernel over given that how it ended up in Linux, or some people still do think it's a great idea? No flame. Just asking about the opinions.
 
You must log in or register to reply here.
Back
Top