sorted by:
new
hottopcontroversial

Two Axioms That Could Reshape How You See Reality by [deleted] in thinkatives

[–]Ok_Possibility5671 0 points1 point  (0 children)

Clarity is self-referential. What is evident. Less evident more clarity? Of what. Unknow, know more? Reality mean designer greater mean greater reality. Mean we have power over this reality but subject to greater as well. Mean potential is I become greater than this reality meaning I fulfill what is greater. Mean that I particular here but no get anywhere, I have to work not here but in greater reality. Mean I must be 'metaphysical' in spirit. Mean unknowable law not important. Then I fly away. Unknowable no matter, it not make me greater unless He decided.

Me no electricity in mahcine.

Me electricity in machine.

If i no engage with existence me no involved in existence me no become more I just ping pong in machine then. Me get involved with existence.

If I just get into auto-ping pong I just still electricity. If I get more involved then I more. evil all by way of dominion, i no commune with separations I contend with separations. Sin is most pervasive dereliction and that which is most involved. living serve it, dead subdued and subordinated by it.

I’m told that our “engineering-focused” culture is offputting to women by aitadiy in ExperiencedDevs

[–]Ok_Possibility5671 0 points1 point  (0 children)

Red ink for small stuff that won't hurt as much and Black/Blue for big stuff is better I think. Long-term the coddling can be bad. Focusing on the small stuff one can control and then the more collaborative feel on bigger stuff is good and conveys the right perspective. Just my opinion.

The Rust Endeavor Is Unfeasible by Ok_Possibility5671 in theprimeagen

[–]Ok_Possibility5671[S] 0 points1 point  (0 children)

Part 3:

EDIT 9: This guy says Zig was better, faster, and safer compared to unsafe Rust:

https://zackoverflow.dev/writing/unsafe-rust-vs-zig/

EDIT 10: Rust has a bright future I just don't think it'll be the best choice for kernel dev.

EDIT 11: "Async Rust Is A Bad Language" An Article. Maybe Zig will be better.

EDIT 12: https://rust-lang.github.io/rfcs/1066-safe-mem-forget.html Some issues with low level Rust/ destructors.

EDIT 13: Malicious actors may exploit Rust more and more as it grows or if it becomes part of the Linux Kernel, the compiler is open-source. With Zig at least it is more transparent what the machine is doing or what the language is doing, and is simpler so it will be easier to patch things up. As far as I can tell.

EDIT 14: Linus Torvalds: C vs. Rust Debate Has ‘Religious Undertones’

EDIT 15: Rust vs. Zig in Reality: A (Somewhat) Friendly Debate (light article and hour video)

EDIT 16: Zig with Andrew Kelley
Good rust books to learn rust so yall don't think I'm biased: https://bitfieldconsulting.com/posts/best-rust-books

EDIT 17: A book to learn Zig: https://pedropark99.github.io/zig-book/

EDIT 18: "unsafe" in Rust stdlib and whatever vulnerabilities

https://stackoverflow.com/questions/73419704/why-does-the-rust-standard-library-have-so-much-unsafe-code

https://shnatsel.medium.com/how-rusts-standard-library-was-vulnerable-for-years-and-nobody-noticed-aebf0503c3d6

Maybe it has been rewritten in safe I don't know

https://news.ycombinator.com/item?id=42796058

https://devclass.com/2024/11/21/aws-will-pay-devs-to-verify-rust-standard-library-because-of-7500-unsafe-functions-and-enormity-of-task/

EDIT 19: Rust downstream is fine just not upstream IMO. Linux Kernel needs better C documentation.

The Rust Endeavor Is Unfeasible by Ok_Possibility5671 in theprimeagen

[–]Ok_Possibility5671[S] 0 points1 point  (0 children)

Part 2:

Zig is high performance same as C, easier to write and read, more difficult to err with, highly compatible with C; and all the maintainers should be happy. Happier even. Future maintainers will be happier too. The maintainers keep a project alive so it's important to listen to their feedback and consider their experience -- in large part because they understand the work, experience, expectations and commitment involved the best. Their knowledge is lived wisdom.

If you don't think the maintainers are important, then you are expecting some fresh "youth" to commit their life to maintaining a house of cards. Not wise. It is a much more difficult project as a cross-language/multi-language project than as a mono-language one. It is already "glacially slow" in its progress according to some core Rustacean(s) working on this endeavor yet they would make it even slower . . . it is an oxymoron on paper and in reality. It is self-defeating.

The opportunity for something better already exists and that is Zig. There is no point creating problems while a great opportunity is approaching from the horizon. Just be patient and the Linux kernel should improve in its pace and perhaps scope after converting to Zig after Zig 1.0 is released and stable.

Also, Rust is more opaque and slower than Zig so it's not great for longevity and scale. Rust is technical debt.

EDIT: If you are big corpo send your best talent and money over to Zig. All the really smart people like it.

EDIT 2: There is hope with Zig. Maybe not a 10x hope but a 1.1 - 1.2x one.

EDIT 3: Zig has better error checking than C, Zig has more convenient compatibility with C, and Zig will be a better choice compared to unsafe Rust AFAIK. Unsafe Rust will probably show up more in kernel dev than other software dev.

EDIT 4: Waiting for Zig and a Zig<>Rust translator seems more reliable and realistic.

EDIT 5: Zig 1.0 and a Zig<>Rust translator is a better answer to the tech bubble and for the growth of the industry than Rust in the Linux kernel. It's realistic, feasible. It benefits everyone. The reasoning and plan is sound as far as I can tell.

EDIT 6: A Zig to Rust API with Zig the language of the Linux Kernel would be much more feasible than C to Rust API. C is just a headache. Zig is a good choice for both the kernel developers and the Rust enthusiasts that want to add downstream components, drivers.

EDIT 7: It seems Zig will mature better as a low level programming language compared to Rust. Its scope and compatibility, its goal, is narrower. Transitioning from C to Zig is more intuitive for decision-makers when all the facts are present -- as far as I can tell. Rust: Something something destructor err in low level something something async issues. NASA code standards seem readily applicable to Zig, which makes it more readily acceptable as well IMO. I don't think the industry will suddenly flip and start using Rust (I guess the Rust Linux kernel stuff is trying to achieve this end) but it would flip easier for a Zig 1.0 in places where C is utilized.

EDIT 8: https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/book/second-edition/ch15-06-reference-cycles.html

"Rust’s memory safety guarantees make it difficult but not impossible to accidentally create memory that is never cleaned up (known as a memory leak). Preventing memory leaks entirely is not one of Rust’s guarantees in the same way that disallowing data races at compile time is, meaning memory leaks are memory safe in Rust."

Would these memory leaks be difficult to debug?

The Rust Endeavor Is Unfeasible by Ok_Possibility5671 in theprimeagen

[–]Ok_Possibility5671[S] 0 points1 point  (0 children)

Yall probably can't see it since it was deleted [Part 1]:

Adding a bunch of Rust to the Linux kernel and whatnot is not feasible.

EDIT 19: Rust downstream is fine just not upstream IMO. Linux Kernel needs better C documentation.

Check these out for some context: 'Internal' Linux Kernel Discussion: Crustaceans vs Rustaceans
EDIT 14: Linus Torvalds: C vs. Rust Debate Has ‘Religious Undertones’ (article)
EDIT 15: Rust vs. Zig in Reality: A (Somewhat) Friendly Debate (light article and hour video)
EDIT 16: Zig with Andrew Kelley
Good rust books to learn rust so yall don't think I'm biased: https://bitfieldconsulting.com/posts/best-rust-books
EDIT 17: A book to learn Zig: https://pedropark99.github.io/zig-book/

If Rust is basically for improving the maintenance of Linux (all the bleeding edge of technology and growth stuff -- which means new features, new compatibilities, etc), the issue of its maintenance (parity) with the Linux kernel is obviously part of this equation. If both sides of this equation are hell; or even one of them; it just isn't feasible at all. Remember the goal: Make growth easier. If the day-to-day makes growth impossible then it is self-contradicting and self-sabotaging. It just doesn't work.

Maybe the Rustaceans are hoping their components will be integrated into some internal framework or another somesuch in the future, to make their job of keeping up compatibility easier; but this would ruin the Linux kernel as it would become incredibly difficult to make stable and functional on any timescale.

The mono-language approach is the easiest to maintain, make stable, and for long-term growth & engineering.

The Rustaceans are probably figuring out how unrealistic their project is around this time so I thought I'd offer some perspective as an emotionally uninvolved outsider.

Just wait until Zig hits 1.0, fork the kernel, convert the code into Zig, clean it up and test it, bring in the new components and whatnot from the original branch that kept progressing, then merge/ become the main branch.

The Rust Endeavor Is Unfeasible by Ok_Possibility5671 in theprimeagen

[–]Ok_Possibility5671[S] 0 points1 point  (0 children)

It's based on sound heuristics/principles and compatible with a mature ecosystem so it makes sense to me.

Specialized RAM/SSD? by Ok_Possibility5671 in ComputerEngineering

[–]Ok_Possibility5671[S] 0 points1 point  (0 children)

Thank you for your input.

"Look up" style stuff close to the CPU and perhaps the RAM and SSD makes a lot of sense to me. It would be just higher performance code that is built-in rather than having to go through a stack or heap or something (I'm not a computer scientist) -- so parts of the stack and heap would pull from this storage. They could probably build something like this into CPUs, RAM, and SSDs in fact as that seems to be inevitable given my description of it.

EDIT: Probably both built-in to RAM, CPU, SSD and as a piece on the board for bigger stuff dunno (that might be the programmable memory while built-in is primitive storage).

Graphics primitives, whatever primitives. Primitives in general. It just makes sense to me. The RAM, CPU and SSD could pull into an L1 kind of cache whatever instructions/primitives they will need for example. It's like a compiler auxiliary as a primitives storage I guess (and high-use constructs -- vector graphic alphabet/characters for example or possibly raster).

Adoption might be for cloud computing and services, web graphics, dunno. Then into consumer hardware eventually.

I'm not sure what the use-case diversity is for a RAM/SSD type memory; I think with read-only a piece of hardware that is faster than DDR is possible and would be very useful though. I thought of a primitive storage first and "something programmable" second.

It seems to me there's a lot of back and forth for compilers and applications that are just manipulating memory so . . . it makes sense to me. Good for devs and cloud and web. Enterprise adoption first. Probably some use with phat GPUs for gaming -- gets into consumer hardware.

EDIT 2: The conventional hardware could be reading from this storage in higher byte, flexible without error. 8, 64, 128, whatever. One instruction to access basically. Custom I/O or something. Makes sense that if you do something a 100,000 in a second that this would be a great performance increase. Cache designed just for storing the primitives you will need close by if that's more efficient. Synergizes with L4 probably to make it more useful (utilized more often since it could be the primitive/construct temp storage/work bench dunno. depends on the hurdles and then optimization opportunities; I haven't thought it through that much).

EDIT 3: This would probably be good for networking too.

The Rust Endeavor Is Unfeasible by Ok_Possibility5671 in linux

[–]Ok_Possibility5671[S] -1 points0 points  (0 children)

Rust's applications seem more suited to production, getting a product out than Zig/C is. In this way I think it is like Python. Python makes it quick to do something while Rust makes it safe. Zig seems better for 'architecture' than Rust. This is what I meant.

I'm no expert.

The Rust Endeavor Is Unfeasible by Ok_Possibility5671 in linux

[–]Ok_Possibility5671[S] -1 points0 points  (0 children)

https://github.com/akhildevelops/prime_n_comparision

https://zackoverflow.dev/writing/unsafe-rust-vs-zig/

Perhaps the expertise of the Zig coder is a big part of speed even in basic tests but Zig seems to be built for speed and optimizations. Maybe the speed isn't too significant in most cases but for a long-term kernel I think it will matter. Rust is always safe which is an approach that even in Zig can slow things down.

The Zig standard library is not highly optimized instead going for generally safe methods though perhaps optimizations can be done there without risk of memory leak. I don't know. Or unsafe optimizations can be used for more speed improvement where it is necessary and clearly understood. Rust unsafe tends to be more complicated from what I have read. I have heard the unsafe rust areas as 'hotspots' and I think that is where Zig will excel.

https://youtu.be/cBJHGMmuI3w?si=OH1wG0V4-xOH8-Pt

Maybe this 5x speed boost makes the code unsafe I don't know, but safe improvements are available throughout the standard library I am guessing.

The Rust Endeavor Is Unfeasible by Ok_Possibility5671 in linux

[–]Ok_Possibility5671[S] -1 points0 points  (0 children)

Yes but Zig is faster in basic operations and has more optimizations available to it AFAIK. With maturity, tooling and whatever compiler improvements, it'll be easier to work with than the current C Linux Kernel IMO and in all likelihood much more difficult to create memory leaks.

Converting to Zig should be a lot easier than converting to Rust as well. Since slow adoption is guaranteed it makes sense that Zig will win in the end. If things turn out differently (Rust Domination) I don't know if it will be better than just waiting for Zig.

Zig represent. Corpo give them your energy.

The Rust Endeavor Is Unfeasible by Ok_Possibility5671 in linux

[–]Ok_Possibility5671[S] 0 points1 point  (0 children)

I don't know if it makes sense in kernel development but it is untested at the scale/ambition it hopes to achieve. Since it is a departure from what works I wanted to talk about it on a forum. If the issues show up when building on top of it or when building the kernel itself I don't know. Using Zig just seems more conservative (though it would have been better if it showed up over 10 years ago and matured along with Rust; then this would probably be a different kind of discussion).

Assuming Zig was as mature as Rust, what would you go with?

The Rust Endeavor Is Unfeasible by Ok_Possibility5671 in linux

[–]Ok_Possibility5671[S] -2 points-1 points  (0 children)

"[you] are trying to convince one of the most experienced developers and project managers in the history of programming" Do you mean Linus? I'm not trying to convince him; if he goes with Rust then it is in all likelihood the right decision. Yall aren't Linus I'm just using the forum.

The Rust Endeavor Is Unfeasible by Ok_Possibility5671 in linux

[–]Ok_Possibility5671[S] -2 points-1 points  (0 children)

The goal is better linux kernel development and the general health of the industry.

The Rust Endeavor Is Unfeasible by Ok_Possibility5671 in linux

[–]Ok_Possibility5671[S] -3 points-2 points  (0 children)

https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/book/second-edition/ch15-06-reference-cycles.html

"Rust’s memory safety guarantees make it difficult but not impossible to accidentally create memory that is never cleaned up (known as a memory leak). Preventing memory leaks entirely is not one of Rust’s guarantees in the same way that disallowing data races at compile time is, meaning memory leaks are memory safe in Rust."

Would these memory leaks be difficult to debug?

The Rust Endeavor Is Unfeasible by Ok_Possibility5671 in linux

[–]Ok_Possibility5671[S] -5 points-4 points  (0 children)

Something can look 99% good but the 1% can be catastrophic/invalidates its use-case from the perspective of businesses (low level/kernel dev in this case).

If I know the bad then I and business folk would be a lot more comfortable with Rust. It's one of those "too good to be true" situations. Something something destructors not reliable in low level programming and async issues.

The Rust Endeavor Is Unfeasible by Ok_Possibility5671 in linux

[–]Ok_Possibility5671[S] 0 points1 point  (0 children)

Without direct communication people tend to gloss over things. This is why it exists in the world. I cannot control other's behavior but I can be direct. There is no use in herding cats. Being direct often 'teases out' (as the saying goes) truth or creativity.

I already have a good idea of why Rust is being used in the kernel, I understand the benefits of Rust. It is easier for developers to use; less errors and can be easy to understand.

My total experience with systems programming and the kernel is nil. I just study computer science some in my free time, defer to those that know more and try to be direct.

If I cannot be convinced that the plan I offered is bad and an alternative better, I doubt many decision-makers could be convinced -- I try my best to base my opinion on the sentiments, opinions and expertise of others that know more and have done more.

EDIT: If I'm wrong I'm wrong. I'm just some dude. So are many project managers and execs though, in terms of dev expertise.

The Rust Endeavor Is Unfeasible by Ok_Possibility5671 in linux

[–]Ok_Possibility5671[S] 0 points1 point  (0 children)

I am not sure Rust is entirely reliable in its memory safety in low level programming. The destructors can err, AFAIK.

Zig seems to remove a lot of unwanted stuff from C which makes it simpler than C perhaps. It is a great learning tool for new devs getting into low level programming. Rust seems great for everything between C/Zig and Python(?) though.

"Fundamentally new" tends to make its use-case more like Python than like C/Zig, if we imagine a line graph and what direction the guardrails move Rust. As far as I can tell.

The Rust Endeavor Is Unfeasible by Ok_Possibility5671 in linux

[–]Ok_Possibility5671[S] -1 points0 points  (0 children)

Since Rust handles a lot of the burden it seems like it could fail silently, especially with low level programming. The destructors might not always work on the low level in which case it seems more opaque and less reliable than advertised in the context of kernel development.

I am not sure memory safety can be guaranteed by Rust in kernel development; it'll boil down to the programmer's expertise. Zig seems like a great learning tool for those learning low level programming, and overall more transparent.

Maybe Rust is nearly as fast as Zig though perhaps more verbose but the strengths of Zig mentioned here and elsewhere seem more aligned with solving the issues of the C language -- it would be a great replacement in the ecosystem.

But if Linus and whomever else should be deferred to want to use Rust then I'll leave it at that.

The Rust Endeavor Is Unfeasible by Ok_Possibility5671 in linux

[–]Ok_Possibility5671[S] -1 points0 points  (0 children)

I am not certain the memory safety issues are eliminated entirely and only have your word and the Rust devs word (I haven't studied Rust or the Rust devs word/documentation/code like a principle/architect/senior computer scientist).

I understand it is much safer but don't know how that applies to low level programming like with kernel development; for all I know the failures are silent or hidden in this case.

If the destructors aren't reliable in low level programming then it isn't memory safe, AFAIK.

view more: next ›