The Layman's Rust Thread

[lost_in_c]

I think there are problems with your reasoning:

C isn't meant to be autogenerated, nor is Rust. Therefore neither one of them is more suitable than the other for autogenerated code.

That's missing the point. Only binary is meant to be autogenerated. Everything after that is an added layer, which slows down the process. I would cut a foot off if many companies don't already have and use kernels generated in binary from autogenerated software. That's not the question here. The question is: if you want to iunsert autogenerated software into the code generation process of a human project that for whatever reason you wish to remain human in some proportion for some amount of time, what language do you use?

It's a little like the reverse problem for humans. If you want to design a program, the most natural and effective way would be to write it out in whatever way is clerest to you. But, because you want thos ideas translated down into machine level, you pick a programming language tht is best suited to the task to the best of your ability to determine that suitability given a range of factors.

The onus here is first and foremost on the autogenerator to close its own feedback loop and magically spawn an ability to judge the quality of its own output.

This is already baked into how autogenerated software is produced. This is why it simply takes input and spits out output in a single step, because all the "judgement" came duirng its "programing." The way these programs are refined is like this:

- Machine, make me a traditional equation that adds 2 + 2!

- fg34g ?

- No!

- 24r=

- Closer...

- etc...

There is no judgement layer. So the only real question, if we take as a given that you want to arrive at a middle point betwqeen optimal computer format and human operatable code, is which language is better suited to shave cycles off of the above illustrated process.

Of course, at times refining one machine to do one thing and another to do another (say, one to generate code and another to check it) is possible and desirable. It is documented practice in autogenerated software engineering. A fact that went straight past all our resident luminaries. And I don't mean luminay sarcastically. It simply shows the problem of a person that is expert forming opinions on something they don't yet realize they are not experts on as well.

Since the days of COBOL humanity has been on a quest to make computers read the minds of very mediocre PHB's with overly tight neckties who don't even know what they think it is they want the computer to do in the first place. Generating any code from that is only the next step. It comes after the mind reading + deconfabulation filter and the error correction of stubborn misconceptions PHB's have of what a computer even is, hence what it is and isn't capable of.

There is a miryiad of ways to solve the problem of "how to get the machine to actually know what it is supposed to produce." Sometimes I think the whole "prompt" phenomenon is meant to intentionally confuse people as to how hard this actually is, which in reality is "not much." I think much of the value of "the prompt" is simply as a tool to adapt people to an autogenerated software everywhere paradigm.

Be that as it may, if you could get autogenerated software to produce a kernel written in human code that far outstrips a human built kernel, then figuring out the prompt seems like a banal afterthought as an accomplishment does it not?

 

[freezr]

For your information, Drew DeVault developed HARE that is meant to create low level stuff like kernel tasks...

The Hare programming language

harelang.org

https://harelang.org/blog/2023-11-08-100-year-language/

 

[Zare]

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.

Hey I wasn't replying to LLM part specifically. But about the attempt of Linux (the project) to draw new developer blood by introducing a language that is rising in popularity.

My claim is it's never the language, but the domain.

 

[lost_in_c]

Ah, I see what you meant.

Frankly, I very much doubt popularity was the real reason. That may have been the way (apparently very convincingly) it was sold to Torvalds, but the entire contention is laughable.

What it might do is draw in the kind of blood that can streamline autogenerated software participation with the least amount of ruffles.

C programmers would jump right on that shit. These Rust cultists are far more likely to go "listen just for now while we gain ground."

 

[lost_in_c]

I think big companies have found that having a free, operational kernel software they can all share is very useful for them, and that they don't want to see some new Microsoft come in and make it all proprietary again. Torvalds lives in some apartment I think. Imagine how much savings for those other companies that thye don't have to pay their software kernel people, or spend hundreds of millions in agreeing on shifting standards.

I think they will do what has to be done to keep it afloat. I at this point cannot understand a universe except where Rust was created on purpose just for this task.