The Layman's Rust Thread

No, that's what I meant. That is only a subset of the capabilities of autogenerated software. It can be set up to take all sorts of input. Or a diverse set of inputs. You can chain them together or in structures.

That's what I meant.
 
But what is interesting in this thread is this: that insofar as autogenerated software may be used to generate code for the Linux kernel, probably Rust would be vastly superior to any other language, to an extent that is not proportional to any possible similar difference in humans. Of course, only to the extent that autogenerated code from autogenerated software is meant to exist side by side with human code.

Otherwise, straight binary would be superior.

Rust is best for this, not only for the reasons stated by me and Mr. Cracauer here, in technical terms of suitability, but because it also:

A. Would gradually require an entire rewrite of the kernel, given its incompatibility with C, and,

B. Is unfriendly to humans, and thus would aid in fazing them out of the kernel development process.

From one perspective, this might be desireable for the simple reason that humans are more expensive per unit of functionality. But viewed rom the other side, from, say, a Linus Torvalds perspective, because it may well be the only viable long-term model for the continued existence of Linux as a maintained and developed project.
 
It increases the efficiency of autogenerated software that might be used to develop Linux, and incentivizes people to come in who have no interest in writing code, but some in writing things in prompts.

At the moment I don't see "incentivized people who come in who have no interest in writing code" as a terrific future for either Linux or the *BSD's. That sounds pretty "no fun".
 
I don't see any "charismatic leader" for FreeBSD. And, in my opinion, it kicks the butt of Linux.

At this point, though, it's really not a matter of what you prefer or what is a rosier future. It is a matter of that Linux is a core component of trillions of dollars' worth of infrastructure. Interested parties aren't going to wait for Torvalds to pass away and a new prophet to come. If one did, he would probably say: "go forth, and leverage autogenerated software."

If you went to an airport, and they told you "you can get on one of these planes that flies itself, or you can walk," maybe you would walk. But I'll tell you this, the airport would not go broke.

I'm sorry to be the one to break it to so many people here. But it's not only the future, it's happening already. This thread isn't even about the proposition that Linux development is undergoing a transition toward autogeneration. We take that as a given, it is happening.

What this thread is about is whether the strange and seemingly discordants things about the "Rust" phenomenon actually indicate that its real purpose is a different one. Maybe, seen in this new light, those outstanding things actually make perfect sense.

This is what we really want to discuss.

The time to kick and scream, if you don't like autogenerated software, was a decade ago.
 
It's interesting that, if this is true, Linus is not only not fighting it, he is encouraging it.

On some level, he understands the situation.

As a bolster to this point: consider cracauer@'s point that actually, Rust is not likely to be very popular among programmers. Then consider that the reason Torvalds quotes for fostering Rust is its popularity, "staying fresh."

He knows.
 
I don't see any "charismatic leader" for FreeBSD. And, in my opinion, it kicks the butt of Linux.

What the f**k are you talking about? Seriously, all of this nonsensical, mental masturbating needs to stop. FreeBSD isn't going to be rewritten in Rust, ever. Better yet, go read the objections from Poul-Henning Kamp on the mailing list and let his insights educate you. And who gives a flying f**k what Linus thinks. He is one renowned kernel engineer compared to many that exist in the FreeBSD developer community. Stop flooding the forums with this BS. If you're so clung onto Rust and its cult, you're better off placing those attachments onto your respective Linux distro community.

I swear, it's like these forums have been infiltrated by paid provocateurs.
 
If Linus is worried about deflation, he should stop the gatekeeping and overreacting against useful stuff like Link tags. The way he handled the Bcachefs situation was just bad. Kent had a point.
 
The way I see it, autogenerated code would not need to use rust. The arguing about memory safety can be done when generating the solution, then generate the code. The code itself needs no checks, it was generated in the knowledge that it is safe.

Whereas I can appreciate that your reasons for being opaque are real, theya re just opaque enough that I can't with certainty tell what you are aiming at. Without lifting opacity altogether, maybe you can give additional remarks.
I would not like to expose the company who did this dumb move (imho), even tough they also tanked my PhD in that process. It's the process of shares and the stock market that deserves that blame.
Other partners were trying to convince them to let the design department continue, being paid from the outside. Nope. Design department for this was closed down, engineers relocated to different places in the company. There were attempts to buy out the complete set of guys and gals, nope. This black magic has a potential to threaten the core products, and even Lockeed Martin threatening you with large suitcases of greenbacks would not chage that.
 
Linux kernel is a huge domain-specific project. An engineer has to, obviously, know the language it was written in, but that is just the thin, stable fundament. Bulk of his knowhow is about the domain stuff. If he's a driver writer he must know how the device and the computer platform interact. Then he must know all the project stuff of Linux kernel, such as facilities in the code, macros, configuration stuff etc.

All of that is far more substantial than language-foo. I'd say it's a 80/20 or even a 90/10 ratio.
 
I don't know any Rust myself. All I think I know about it, is what I read. And that tells me Rust is more complicated than C.
Further I understand LLM helps to write code, but you need experienced programmers to get the code produced right, and to review, test, and debug it, anyway.
So if there is a deflation in programmers - fewer programmers willing to do the work; fewer programmers able to do the work - which to me doesn't have to be that drastic, since I believe most open source projects lack of programmers chronically, my question is:
How can switching to a more complicated language solve that issue, since to my understanding it will even worsen the situation?
 
Code is for humans. Always was. So now that we have LLM's reading and writing code, that situation is suboptimal. Rust is yet another programming language, that I know and use for many things nowadays, but it's still for humans to read and write. If we really want to go for autogenerated, then code (the language) should be optimized for what an LLM understands optimally. A bit like how there's now a new data format named TOON, optimized to reduce the number of tokens burned when compared to things like JSON (although JSON should not be human-read or human-generated either). What TOON is for data interchange in an environment where LLM's play a role, Rust is *NOT* that for programming languages.

Having stepped into Rust from an ancient background in 8-bit Assembler and some very basic C++ experience from well over a decade ago, I don't really see what's there to hate about Rust. Sure, grafting Rust onto a large code base in C or any other language seems like the road to madness. But in and of itself, as a language to write application and backend service code in, I definitely like it. It's never been easier for me to write a HTTPS backend for some tiny service I needed that's both easy to maintain, operationally very stable and bloody fast on a matchbox like a Raspbery Pi.
 
What the f**k are you talking about? Seriously, all of this nonsensical, mental masturbating needs to stop. FreeBSD isn't going to be rewritten in Rust, ever. Better yet, go read the objections from Poul-Henning Kamp on the mailing list and let his insights educate you. And who gives a flying f**k what Linus thinks. He is one renowned kernel engineer compared to many that exist in the FreeBSD developer community. Stop flooding the forums with this BS. If you're so clung onto Rust and its cult, you're better off placing those attachments onto your respective Linux distro community.

I swear, it's like these forums have been infiltrated by paid provocateurs.

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

For what it's worth, I myself am not a fan of the idea of Rust in FreeBSD base. I would, nevertheless, need to defer on that point to far more knowledgeable people like cracauer@ and those he is conversing with on the Case for Rust in Base thread linked in the OP.

This thread is not about campaigning for anything. It is about coming to grips with things going on now, why they are happening, and what they mean. This requires a cold head and calm nerves, not feverish reactions.
 
If Linus is worried about deflation, he should stop the gatekeeping and overreacting against useful stuff like Link tags. The way he handled the Bcachefs situation was just bad. Kent had a point.

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.
 
The way I see it, autogenerated code would not need to use rust. The arguing about memory safety can be done when generating the solution, then generate the code. The code itself needs no checks, it was generated in the knowledge that it is safe.

But that's the whole question. A human first comes up with a design, and then implements it in code. Autogenerated software does not function that way. Autogenerated software takes input, tries to guess what the following bytes should be, and prints them. It makes this guess based on a long previous process of refining logic gates via algorhythms using test input and desired output.

In other words, a human may see less benefit from a language that enforces memory safety, when for him the problem is in a previous, design step, than a computer running autogenerted software would, where there is only the output stage. The output would not be kernel binary, it would be kernel code. Would Rust not be more amenable to this than C? The more I think about it, the more I think the answer is "clearly yes, probably measurable in the dozens of cents per dollar."
 
Linux kernel is a huge domain-specific project. An engineer has to, obviously, know the language it was written in, but that is just the thin, stable fundament. Bulk of his knowhow is about the domain stuff. If he's a driver writer he must know how the device and the computer platform interact. Then he must know all the project stuff of Linux kernel, such as facilities in the code, macros, configuration stuff etc.

All of that is far more substantial than language-foo. I'd say it's a 80/20 or even a 90/10 ratio.

See my reply to Crivens. This would be very relevant for people, who design conceptually first and output code after. An autogenerated software has no concepts, it has to arrive at the correct code by guessing it. In that scenario, language-foo acquires a higher ratio.
 
How can switching to a more complicated language solve that issue, since to my understanding it will even worsen the situation?

I'm not saying it would solve it. I'm saying that it may make the solution considerably more cost effective. Rust may be more complicated for humans, but it is likely to be simpler for machines running autogenerated software than C is. My opinion. Still to see a convincing counterfactual.
 
Code is for humans. Always was. So now that we have LLM's reading and writing code, that situation is suboptimal. Rust is yet another programming language, that I know and use for many things nowadays, but it's still for humans to read and write. If we really want to go for autogenerated, then code (the language) should be optimized for what an LLM understands optimally. A bit like how there's now a new data format named TOON, optimized to reduce the number of tokens burned when compared to things like JSON (although JSON should not be human-read or human-generated either). What TOON is for data interchange in an environment where LLM's play a role, Rust is *NOT* that for programming languages.

Having stepped into Rust from an ancient background in 8-bit Assembler and some very basic C++ experience from well over a decade ago, I don't really see what's there to hate about Rust. Sure, grafting Rust onto a large code base in C or any other language seems like the road to madness. But in and of itself, as a language to write application and backend service code in, I definitely like it. It's never been easier for me to write a HTTPS backend for some tiny service I needed that's both easy to maintain, operationally very stable and bloody fast on a matchbox like a Raspbery Pi.


I am really not making value judgements in this thread. I may have all sorts of opinions on Rust, but that is not what this thread is about.

The important thing regarding the things you write is that, in fact, using no code would be most optimal for autogenerted software by a long shot. It would be far, far more optimal for it to just spit out binary. The question here is, given a situation where you want to insert autogenerated software into an environment where you forsee human participation, and even human leaderhsip, for the next several years, would there be a positive cost benefit equation to gradually switching to Rust?

Is Rust less ineffective for machines than, for example, C, and by enough of a margin to make the shock of the transition worth it?

For reasons stated repeatedly throughout this thread, I believe the answer is yes. I am interested in reading reasosns why not, but so far I have not read any convincing ones, or even many attempts. Most interventions have been about unrelated matters.
 
I'm not saying it would solve it.
Nah. I never said, you said that. My concern was meant more general. As you already said yourself, this ain't the first 'Rust'-discussion here. My simple concern is:
If there already is a shortage of programmers, wouldn't it worsen the situation if to switch to a language that is more complicated, so used by even fewer programmers?

I think one of the core points is, those discussions are quality based, but lack of numbers. So advantages, benefits, and downsides cannot be weight in relation to each other.
Maybe what I wanna say becomes more clear when I give a silly example. The numbers are completely made up BS - I don't know any (maybe somebody can help?) - but just for to sketch the idea:
How many programmers are in the world capable of programming in C on a professional level? 10 Million? (More? Less? I don't know.)
How many programmers there are capable of doing work at a professional level in Rust? 1/2 million? Again: I have not the slightest idea. But I guess it's magnitudes smaller.
How much percentage is doing work on open source projects? This percentage does not depend on the programming language, except I believe with Rust it does. Rust is new. And Rust programmers are wanted by Google, Microsoft, and others, who pay well. So I see with Rust fewer people doing work on open source, as on other languages.

My point is: The pool you may have access to recruit programmers from with Rust is way much smaller. (Again: I maybe completely wrong, since I don't know any actual numbers.)
So maybe apart from all benefits Rust may, and will have, there simply may be too few programmers available to keep something like FreeBSD alive.

As I said: I don't know.
But I think this is some point, needs to be considered, too, not the pure qualitative, technical aspects, only.
 
Nah. I never said, you said that. My concern was meant more general. As you already said yourself, this ain't the first 'Rust'-discussion here. My simple concern is:
If there already is a shortage of programmers, wouldn't it worsen the situation if to switch to a language that is more complicated, so used by even fewer programmers?

Look, my opinion is that yes, it makes it worse. I like my software designed by meat.

But I'm just an asshole on the internet. The real question is, what do people with access to trillions of dollars think?

Do those thoughts of those people explain some of what I whole-heartedly agree is the extreme cult-like behaviour of Rust advocates? After all, a cult is a system that recruits people first and foremost, leveraginmg ther desire to belong against any other possibly critical considerations.

I don't think there is anything to do at this point about developer deflation. I think elite institutions like the FreeBSD development team have a much better chance than others, such as Linux, and hope it will remain human, and believe keeping Rust out would help that. But even this is not even vaguely in my hands.

My interest is in understanding what is happening, not deciding what I want to happen. I invite others to do the same, so that maybe we may be of use to eachother in deepening this understanding.
 
I'm not saying it would solve it. I'm saying that it may make the solution considerably more cost effective. Rust may be more complicated for humans, but it is likely to be simpler for machines running autogenerated software than C is. My opinion. Still to see a convincing counterfactual.

You could conduct a test. Take some LLM and let it write some Rust program, something with a bit of bite in data structures. Try to compile it. If you are like me you'll find compile time errors galore.

Of course that is "not a problem" if you use a language with no compile time checks such as Python.
 
But python is no good, because it is too slow for systems. I use a browser coded in python, and it is retarded slow compared to a normal browser. The design is beautiful enought hat I keep it, but the point is, it doesn't have to be good. It just has to be better than C (for machines).
 
By the way, just because whatever autogenerted porgram you are using outputs X, doesn't mean the intended actual autogenerated program would output the same. There is a distinction in autogenerated software engineering between testing data, refining data, and then actual desired output.

In other words, for all you know, you are just refining an autogenerated software paradigm, rather than intended to leverage it yourself. We can't really know.

If we want the answer to this one, we are much likelier to arrive at it by analyzing in theoretical terms what strengths Rust may or may not have vis a vis C for this use case.

My opinion.
 
But I'm just an asshole on the internet. The real question is, what do people with access to trillions of dollars think?
That indeed is the question. Also, how good does that thinking model reality? How much will that thinking hurt each one of us (Joe Sixpack, Ivan Ivanovich, ...). If there is a god, maybe he should put a quota on how much power any one person might be allowed to command. Sadly, the design was done with FAT in mind.
 
But python is no good, because it is too slow for systems. I use a browser coded in python, and it is retarded slow compared to a normal browser. The design is beautiful enought hat I keep it, but the point is, it doesn't have to be good. It just has to be better than C (for machines).

I was sarcastic with my Python mention. Of course it is near suicidal to "solve" the problem of compile-time errors by using a language with no compile-time checking. The same errors are still in there, but the program starts and throws the errors to the user, not the programmer.
 
Back
Top