The Layman's Rust Thread

[Crivens]

Of course it is near suicidal to "solve" the problem of compile-time errors by using a language with no compile-time checking.

The think is, you can fix these errors in a higher level much easier than in the lower ones. Once upon a time, C compilers wrote out assembler code files. The assembler proviedes no error or type checking, but when that is done on the upper levels it does not need to.

But all, don't forget the compiler writers full employment theorem. The perfect compiler could solve the halting problem, which can not be solved. So there we go. No LLM generated code can be perfect because the LLM has limits in itself to understand all it needs to understand (as if it could) to do the korrect thing.

 

[mer]

I don't know if I've just gotten lost in the weeds on this discussion, but I thought it started out as basically "Is Rust a good candidate for autogenerated code".
Without getting wrapped up in "Rust", I keep coming back to who/how verifies that autogenerated code is correct?
Anyone that has developed code, typically has requirements, then gets handed off to a QA org. The best QA folk will test to the requirements but will also test outside the bounds.
Yes automated/autogenerated tools can do this but don't they typically need to be told/guided to?
I'm getting hung up on the "for autogenerated code how/who verifies it's correct"

 

[cracauer@]

I don't know if I've just gotten lost in the weeds on this discussion, but I thought it started out as basically "Is Rust a good candidate for autogenerated code".
Without getting wrapped up in "Rust", I keep coming back to who/how verifies that autogenerated code is correct?
Anyone that has developed code, typically has requirements, then gets handed off to a QA org. The best QA folk will test to the requirements but will also test outside the bounds.
Yes automated/autogenerated tools can do this but don't they typically need to be told/guided to?
I'm getting hung up on the "for autogenerated code how/who verifies it's correct"

LLM will generate test cases with the code if you ask them to. But good luck making them troll the edge cases. Or for that matter, good luck making human QA cover the edge cases.

 

[Espionage724]

What I don't think he quite goes on to connect is that Rust will probably help solve long-term maintenance problems with Linux, not because Rust has somehow caught like wildfire among programmers, but because Rust is probably a far more autogenerated code-friendly language than C. Not only in real terms, but most likely in perceived terms of autogenerated software companies.

It sounds like there isn't an appeal for lower-level programming, but new devs are interested in higher-level languages.

It could be that Linux is interested in becoming more-open to newcomers (for Linux's benefit of being "the OS"), while newcomers aren't interested in the low-level upbringings. So cover-up the low-level stuff with new shiny stuff

But python is no good, because it is too slow for systems.

A Google IT professionals course years ago mentioned Python being used for OS-level scripting (like Bash); I thought that was wild: Why would I want to use higher-level stuff instead of the OS's lower-level native tools?

Yeah but to attract people you have to give them something fun to do.

Pay em

I have interest in improving low-level tech in traditional C or C++, and vested interest in performance-seeking with gaming. I could learn low-level languages and get into communities/groups to improve something (and long-term investment because once I know what I'm doing and to look for, nothing is safe from improvement ), but that's not immediately benefiting me: I use existing software to get stuff done that's more-fun to do for free. Linux (imo) wants the easy way of attracting new devs.

---

I haven't heard back from that Graphics Stack position, but I assume they want someone already having the years of C experience. C hasn't been required for anything I've done so far, so learning it wouldn't have the required-interest while doing it for free for vague employment possibilities, and without the legitimate interest, learning fundamentals could be questionable (might I learn the bare-minimal fast with shortcuts just for credentials? Might this be similar to some learning Rust today?).

Mind the graphics stack already works for what I need it for on Windows no-coding-required, and being unpaid lets me switch to any OS freely as long as it lets me do whatever I want done. Afaik that FreeBSD position wasn't paying for school/resources to learn C, even for candidates meeting the passion required for legitimate improvements.

 

[mer]

LLM will generate test cases with the code if you ask them to. But good luck making them troll the edge cases. Or for that matter, good luck making human QA cover the edge cases.

Agreed, but I've been lucky to work with one or two human QA over 40 yrs that started with the edge cases. And yes those one or two QA actually worked with dev actually asking "hey I saw something weird is this a bug" so we could discuss and decide FAD or "yeah go bug it".

 

[cracauer@]

A Google IT professionals course years ago mentioned Python being used for OS-level scripting (like Bash); I thought that was wild: Why would I want to use higher-level stuff instead of the OS's lower-level native tools?

That's where Golang came in.

Google was Python on the SRE side and partially C++ on the SWE side. Golang was intended at Google as a replacement for C++. The C++ folks wouldn't have any of that. But the Python crowd jumped on Golang big time, mainly for static type checking.

 

[mer]

It sounds like there isn't an appeal for lower-level programming, but new devs are interested in higher-level languages.

I think higher level stuff lets you present a lot of bling, a flashing spinning gui that managers can understand.
Low level/device driver folk get excited over setting a LED, getting a character on the screen. Managers are always "yeah but if I press a key isn't that supposed to happen?" without acknowledging the levels of crap underneath

 

[lost_in_c]

I don't know if I've just gotten lost in the weeds on this discussion, but I thought it started out as basically "Is Rust a good candidate for autogenerated code".
Without getting wrapped up in "Rust", I keep coming back to who/how verifies that autogenerated code is correct?

Yes, well, imagine my frustration. I can get people to go on and on about autogenerated software, or Rust, or Rust's suitability for humans, or autogenerated software vs humans for kernel development, but I CANNOT get anybody to engage more than extremely briefly with "would Rust be superior to C for autogenerated software to produce kernel code."

People that herd cats would use this thread as a metaphore when they felt their task was more difficult than usual.


As to QA, one important thing to realize is this: any task a human can accomplish, an autogenerated program can also. For example, you read many people saying they write their own code, but then use autogenerated programs to check it. You could easily generate one to code, another to check, etc.

The question is never whether autogenerated software can do what a human can. The question is only ever what the cost-efficency difference is.

Nostalgia is not an argument. Also, the idea that trillions of dollars will be left unattended is foolish. Either trained professionals, or dictatorial govenrments, somebody will make it their businesss. Because not worrying about it is nihilistic nonesense.

So. Let's imagine in a fantasy land that doesn't exist, totally made up. In this fantasy land, programs can be autogenerated. In that fantasy totally made up land, would C or Rust be better to generate for kernel code, and by how much? Let's say it has to be one of those two, because otherwise you cannot penetrate a human project, or because evil monsters will drag you to a ultradimension, whichever. Which langauge, and why?

 

[lost_in_c]

It sounds like there isn't an appeal for lower-level programming, but new devs are interested in higher-level languages.

It could be that Linux is interested in becoming more-open to newcomers (for Linux's benefit of being "the OS"), while newcomers aren't interested in the low-level upbringings. So cover-up the low-level stuff with new shiny stuff


A Google IT professionals course years ago mentioned Python being used for OS-level scripting (like Bash); I thought that was wild: Why would I want to use higher-level stuff instead of the OS's lower-level native tools?


Pay em

I have interest in improving low-level tech in traditional C or C++, and vested interest in performance-seeking with gaming. I could learn low-level languages and get into communities/groups to improve something (and long-term investment because once I know what I'm doing and to look for, nothing is safe from improvement ), but that's not immediately benefiting me: I use existing software to get stuff done that's more-fun to do for free. Linux (imo) wants the easy way of attracting new devs.

---

I haven't heard back from that Graphics Stack position, but I assume they want someone already having the years of C experience. C hasn't been required for anything I've done so far, so learning it wouldn't have the required-interest while doing it for free for vague employment possibilities, and without the legitimate interest, learning fundamentals could be questionable (might I learn the bare-minimal fast with shortcuts just for credentials? Might this be similar to some learning Rust today?).

Mind the graphics stack already works for what I need it for on Windows no-coding-required, and being unpaid lets me switch to any OS freely as long as it lets me do whatever I want done. Afaik that FreeBSD position wasn't paying for school/resources to learn C, even for candidates meeting the passion required for legitimate improvements.

I think the issue here is that senior C developers grew up in a world where jobs for C coding where plentiful. You went out into the field and then they could hunt you from that field for open source projects of the magnitutde of a widely used kernel. They are not prepared, nor should they be held responsible, nor is it necessarily sustainable as a model for them, to catch eager talent and shape it into a developer for their project. Where will the money come from?

If people don't learn C anymore (or, if we are honest, other than a few screetchignly loud individuals and your odd sensible senior developer, Rust), it's not likely to be because people suddenly got lazier. Young people always seem lazy to older ones, that has been true for as long as humans have existed. Probably, the market is just not there for it like it used to be.

There are all sorts of variables involved as to why. A lot of them are very creepy. Much that is going on today is mighty creepy.

That has no bearing on the truth of it. These are the facts. Fewer people are trained in systems programming, and that number will continue to decrease. Ditto for userland programming, frankly. A Java developper is far more likely to feel no pride lost at having autogenerated software produce the code for them. We're going to pretend this is not true? Systems people tend to have more authorship pride. And even them, if it were possible, I would be interested in seeing proportion of autogenerated code figures for.

 

[cracauer@]

Of course you want the language with the most compile-time checking for LLM generated code. We covered that.

 

[lost_in_c]

That's one of the things we covered.

 

[lost_in_c]

But, I mean, I'll take it. You are on the side of "yes Rust is superior for autogenerated programs to autogenerate code for."

For the reason that it poses many more enforced limits than C, which is more beneficial, proportionally, to computers than it is to people.

 

[lost_in_c]

Also, the compilation time checking is tied to the syntax. Which is what autogenerated machines would be refining on. The syntax itself promotes keeping track of memory, in a whay that C doesn't. C leaves that much more as a loose end, even syntactically, for the developer to figure out on a design plane before ever putting pen to paper.

No?

This whole stereotype that Rust developers think that if a thing compiles, it works. Maybe there is some truth to that stereotype. Getting autogenerated software to reach a point where it doesn't trigger compile errors is a far simpler (read: cheaper) task than getting it to magically know what to do with memory. A human has the added abstraction of design, but a computer doesn't. A computer would have to make statistical ties between very disparate elements in order to arrive at a memory paradigm (which it eventually would). How many rounds of refining are you shaving off by just needing to have it pass a compile check, or produce a syntax that already has built-in memory tracking?

Enough to design and deploy an entire language that is functionally only marginally different from C for humans, and force it down the throat of the world?

 

[rbranco]

Agree on all points.

Sort of.

On a deeper level, even if Torvalds enforced all the policies which I agree would bring in actual competent motivated developers, even if he grew the proportion of Linux developers of the wider developer pool, that would probably still not produce the influx Linux needs.

This is not meant in the sense that I am proposing they should do this or that. This is meant in the sense that I believe they already arrived at this conclusion themselves long ago, or maybe even had a hand in bringing about the situation that made it inevitable, and put into motion a strategy that I believe may very well include the creation and propagation of the Rust programming language.

To me, Rust just doesn't belong in the Linux kernel, BSD, Illumos, etc.

Rust devs hate C so much that they won't be the ones maintaining all the code needed to glue C & Rust.

But I think that Rust devs are just wired differently. I think Rust may be good for graphics drivers and stuff. But leave the kernel & existing userland alone or just make RedoxOS happen. Rust devs are also a ageist bunch and RedoxOS being a micro-kernel would enable them to look down on monolithic kernels as old relics.

I find the current relationship with Rust devs asking for acceptance while denigrating everything C a bit parasitic. I do respect the RedoxOS developers for doing their stuff quietly without making a fuzz about it.

 

[RetroComputingCollector]

Generated code is fine if the generator is controlled by a competent human. Heck, they built an entire programming language around generics (C++).

Copyright holders would disagree with you.

 

[lost_in_c]

Rust devs hate C so much that they won't be the ones maintaining all the code needed to glue C & Rust.

I think this point is even more important than one might think. The antagonism + the structural incompatibility would leave two-choices long run: deprecate C (as they have explicitly stated is their goal), ie, rewrite the kernel in Rust; or leave Rust out. Otherwise, maintenance is a lie in the long run. Nobody will in good faith maintain a binary system.

Add to that that the amount of people using Rust is and will be even smaller than the already small amount of people that can do C on the kernel level, you are basically forcing the use of autogenerated software.

Which adds to my point. It's not only Rust's compatibility with machines that makes it ideal for autogenerated software, it's its incompatibility with humans. It's not incompatible enough that it stops human adoption, but maybe it is enough to gradually displace human code generation.

It's hard to believe these circumstances came about coincidentally.

 

[Beastie7]

It might help you to deflate your emotions if you wish a clear and cold understanding of these important issues.

Except these aren't important issues. These discussions were nonexistent until the Linux community decided to adopt Rust in their mainline tree. Linux migrants flock to the FreeBSD forums thinking it's going to adopt whatever new shiny-ness the Linux community is experimenting with. FreeBSD isn't some toy platform.

 

[Espionage724]

Which adds to my point. It's not only Rust's compatibility with machines that makes it ideal for autogenerated software, it's its incompatibility with humans. It's not incompatible enough that it stops human adoption, but maybe it is enough to gradually displace human code generation.

Produce code so confusing to humans nobody will notice a backdoor

 

[lost_in_c]

Produce code so confusing to humans nobody will notice a backdoor

Among a myriad possibilities. Nothing like opaqueness to gain control.

Except these aren't important issues. These discussions were nonexistent until the Linux community decided to adopt Rust in their mainline tree. Linux migrants flock to the FreeBSD forums thinking it's going to adopt whatever new shiny-ness the Linux community is experimenting with. FreeBSD isn't some toy platform.

Right, except th people making a serious push for adoption of Rust in FreeBSD base are long-time FreeBSD developers. Go figure.

Many discussions that are relevant today were not months ago. Things are moving fast. Again, unless you are fine being algea in the current, maybe cool your brain.

A more important question than when Rust started being a topic is why Rust made it into the Linux tree. Seriously, did you ever ask yourself that? And why is it now being suggested (by long time FreeBSD contributors) for FreeBSD?

Nobody has been able to point out any emergency it is solving. The best some people have managed to do is show some debateable advantages vis a vis memory allocation, without addressing any of the many problems it poses. A lot of very screetchy, ill-bred and frankly culty people have yelled about it very loudly (and very rudely). Those people claim C is obsolete. They have not made any very convincing case.

Yet the open source world (and, for all we know, the closed source world) is being turned upside down on its account.

Is that not fucking a little bit interesting?

No, wait, let's all keep yelling in panic. I am sure a disruptive actor would not find that useful.