way-cooler.org/blog/2019/04/29/rewriting-way-cooler-in-c.html >Currently there is 11 THOUSAND lines of Rust in wlroots-rs. All of this code is just wrapper code, it doesn’t do anything but memory management. This isn’t just repeated code either, I defined a very complicated and ugly macro to try to make it easier.
>This wrapper code doesn’t cover even half of the API surface of wlroots. It’s exhausting writing wlroots-rs code, memory management is constantly on my mind because that’s the whole purpose of the library. It’s a very boring problem and it’s always at odds with usability
>I can always just use unsafe bindings to wlroots, just like I would with any other language. However, the entire point of Rust is that it’s safe. Doing that is not an option because at that point you lose the entire benefit of the language.
>Starting with this PR, the compositor for Way Cooler will be written in C. >Now it makes sense for it to be written in C, given the constraints that I have discovered through painful trial and error, so it will be written in C.
>rewriting a library for the sake of only using Rust is not good engineering. A literal rewrite of a project to Rust is not interesting, it’s not useful >Time would be better spent either working with existing solutions that already have the effort put in
You literally cannot do anything useful in Rust. 11 thousand LoC just to wrap a library.
>Smithay is a library similar to wlroots, but is written entirely in Rust. I’m not interested in trying to use Smithay for Way Cooler.
>Smithay is very incomplete. Very, very incomplete compared to wlroots. It is no where near usable and the current trajectory doesn’t look like it will be usable very soon either. wlroots is a great framework and has a strong backing in the community so I don’t see the need to abandon it just so I can keep using Rust.
>Way Cooler will have to talk to C libraries any ways (the rest of the Wayland ecosystem is all C, including libinput, DRM, and OpenGL), so either more bindings will need to be written (again distracting from the main problem of making a working compositor) or they will need to be RiiR.
So much for existing Rust tools being better, and so much for Rust C ABI interoperability.
Owen Fisher
But a ton of projects have already been rewritten in Rust. From the blog itself: >As an interesting side note: both developers behind those particular projects have elected to rewrite their projects in Rust.
Ian Adams
There are a lot of Rust shills on Jow Forums It's almost as bad as mac shills pre-Satania
Fervent fanboys and shills spread that shit all of the time. I work on wlroots, and it's not an uncommon occurrence for people to come to our issue tracker or IRC channel and bring that shit up.
What's worse is that it's always non-developers and people who aren't actually going to put in any work.
Good job wasting like 3 years of effort on something people have already done for you. That doesn't address anything to address all of the other C libraries, though. We honestly use over 15 C libraries in wlroots; are you going to rewrite those too? That includes Mesa, which is literally your GPU driver and has over 2 million lines of code. >just use unsafe retard Why are you even wasting your time, then?
If I wasn't so jewish with my money, I'd unironically give money to your patron drew.
Jordan Bailey
I'm not Drew.
Gabriel Jackson
It's almost literally their slogan.
Oliver Martinez
yes, and having no actual argument so it does fucking nothing.
Jose Jones
Wayland is already enough of a shitshow, no need for Rust to turn into a legacy XFree86 type of hell.
Jaxson Baker
we're not the ones randomly trying to interject some shit language into every conversation take your trash fetish language and shove it up your ass.
Robert Smith
wayland already works tho
Camden Scott
neither am i, i could highlight the portion of the C community that claims other languages don't need to exist and all webpages should be written in C and that it's the only beautiful and pure language (along with Go, depending on who you ask) and claim that all C programmers are like this, or i can even say you're a tranny if you use linux because trans people have worked on it. this is your argument. flawless, really.
Daniel Perez
That's retarded, Rust has other benefits, too, not just muh safety. It has modern language features like tagged unions, pattern matching, generics, closures and so on...
Really the only thing unsafe Rust adds are dereferencing/casting arbitrary pointers and calling C functions. Even the borrow checker is still in effect. I don't know about wl-roots, or his wrapper, but that argument itself is stupid.
Nolan Nelson
>numerous opaque objects from various C garbage being mapped into your memory space are hard to work with in a language designed explicitly with ownership and safety.
gee, no shit. wouldn't shock me if there are bugs in the c code he's trying to wrap.
Joshua Fisher
this, the project was retarded to begin with. it's trying to glue together 2 polar opposite memory management philosophies and damn it didn't work who could've seen that one coming
Mason Diaz
So, Rust is never allowed to use C libraries? What a fucking joke of a language. How on earth are you expecting to be adopted when you try and exist in your own little bubble? That's literally the opposite of the approach you need to take for a system's programming language.
Gabriel Taylor
just use unsafe for the bindings retard
thats all we are saying
Luis Cox
>rust is never allowed to use C libraries are you iterally braindead? of course it is. the library author was trying to bind rust's memory manager to the C memory management functions, which is nonsense. you can use raw bindings like in every other language, the problem arised when he tried to make it one step further and make it not just bindings but a full on wrapper in a language that completely disagrees with C memory management patterns.
Robert Price
>So, Rust is never allowed to use C libraries?
no one said that explicitly, but if by C library, you mean some fucking big ass nightmare that throws you structs that might as well be opaque and can magically explode in some confusing event loop you don't control, no shit?
this isn't any different than trying to throw something like Qt and some TAO together in C++ where both shitty libs have their own event loops and thus have their own lifecycle management and shit.
This was doomed to fail miserably from the start.
Gavin Thomas
tried to take it* doesn't really matter makes sense either way but it bothers me a bit
Charles Brown
>This was doomed to fail miserably from the start. They're continuing with C, nothing has failed. Rust is the failure.
Joseph Johnson
>Rust is the failure. >a language is a failure for having lacking semantics and insight into a massive system that handles ownership and lifetime in primitive ways.
ok kid.
Levi Powell
seething
Colton Thompson
you seem awfully ass inflamed for someone who claims to have ~real rust discussions~ on Jow Forums despite no one actually going out of their way to laugh at you for it
maybe you are that retard who constantly makes off-topic one word "Rust!" replies to everyone in /dpt/. because I have laughed at you a lot
Ryder Jones
i bet he is drew himself
realizing that this was a bad idea since the very beginning
Jack Thompson
I had a similar experience trying to wrap libwayland a few years ago.
The problem is that it uses the typical C style of memory management, where there's no real thought put into ownership or object lifetimes. Got a pointer to a thing? Feel free to deallocate it, or deallocate anything reachable from it (which is usually a good chunk of the entire program state). Oh, you're in a callback three levels deep below a function that may or may not have its own handle to the thing you're deleting? Well, it's probably okay as long as all your callers don't touch the object AFTER they call you... (>what is abstraction, lul)
The tradeoff Rust makes is that if you do some work to shape your program's ownership model into something the compiler can reason about, then (surprise) the compiler will help you reason about it and tell you if you fucked something up. But when the ownership model of the underlying library is "total clusterfuck", adapting that to something rustc-friendly is extremely difficult and requires reasoning about loads of tricky, poorly-documented corner cases.
By the way, as for my own libwayland wrapper: I ragequit and RIIR, just implementing the Wayland wire protocol directly.
Brody Sanders
Read These Rust rewrites/implementations are utterly worthless, probably just resume builder hobby experience for college kids who got indoctrinated with "memory safety" and other gimmicks.
Kevin White
>just use unsafe Creating these "safe" binding libraries are all Rust-fags seem to do. Pushing this type of complexity into the application code is just going to be a fucking mess, and lead to horrible code.
wlroots is a very pervasive library. It's not a case of "call func, get result", it has a very profound way on how the program is structured. Most things are callback based and asynchronous. It's designed this way because it inherits it from libwayland-server, and is a natural way to design a program like this.
The fact that Rust is so utterly incapable of ergonomically using what I wouldn't call a particularly far-fetched design just shows a massive flaw in Rust. But that's really the whole thing about Rust I hate the most: all they say is "You have to do things MY way, or you can go fuck yourself", which applies to basically everything, not just the borrow checker.
Carter Davis
>*makes false assumptions* >ALSO take your trash language and shove it up your ass yeah I'm the inflamed one here user. also no argument.
Logan Young
maybe you should read my posts you fucking stupid ass child.
These problems aren't unique to MUH C AND RUST. I have SEEN these problems in a literal C++ project, where incorporating different C++ code can cause massive problems and incredible software complexity to manage it correctly. Rust code on Rust code could also theoretically be as problematic and so can C on C. As long as your language allows you to make strong independent garbage who don't need no runtime, you can write yourself into the very same problems this tard ass blogger did.
That's how SOFTWARE works.
now fuck off you fucking retarded shitter C tard faggot.
Charles Taylor
Why the hell did Rust create so many rabid fanbois? Is this where all the Ruby fags went after RoR went to shit?
Andrew Martinez
Rewriting firefox is literally the reason of why rust was created. You don't dare to come here and tell lies about shit that happened yesterday, you fucking nigger.
Ryan Gray
its not MY way, its just the only solution
you cant make rust work with obscure objects you just cant, so yes, go fuck yourself
use raw bindings, not a full blown wrapper
Landon Wilson
>wayland Burn it with fire
Blake Jenkins
implement complex layouts already, I need it for my dual display port monitor
Bentley Green
>where there's no real thought put into ownership or object lifetimes How so exactly? The "typical" C memory management for libraries is to leave it to the programmer. Hence returning null, which the programmer should check. And the programmer calls free themselves and knows not to use objects after that.
I'm not really a sway developer, I work on wlroots. But why don't you just have a go at doing it? The best way to get something you want is to do it yourself.
ok and? I don't even use rust or have a single meaningful rust project. stay buttblasted, no argument c babby.
Blake Martin
Oh damn this is complex.
Chase Jenkins
>Hence returning null, which the programmer should check. And the programmer calls free themselves and knows not to use objects after that.
jesus fuck. people defend shit that can be solved by a thought out lifetime and a good type system? What's next, is type inference the devil too?
Wyatt Sanchez
Are you retarded? C actually allows you to have OOM checks, which is something a robust piece of software actually wants to deal with. Rust's approach is "just panic, lol".
That also isn't related to ownership. Most C programs actually have a very structured ownership model, and it only fucks up if you're an idiot who doesn't follow it.
Ethan Harris
>C actually allows you to have OOM checks >muh memory manager threw me an error I don't properly handle or unwrap >this is the same thing as detecting an OOM
panicking is a hell of a lot smarter given it preserves the runtime expectations of the language.
and good for your shitty C code's ownershit model, where the onus is understanding code that could easily be known automatically, for the most part, by a computer. you're really proud of doing bitch work I see and significantly overloading your mind with details that can be deadly if not handled correctly.
Gabriel Williams
The entire point of C is that it doesn't hide any shit from you. C programmers understand and appreciate that. Complaining to C programmers that it's not hiding enough is just barking up the wrong tree. It's literally a feature of the language.
Josiah Bailey
>The entire point of C is that it doesn't hide any shit from you
except you're wrong moron? literally even trivial optimizations can hide a huge amount. such as "optimizing out" what is assumed useless code, automagic platform specific vectorization and much more. hell if you're using something "considered undefined" you're inviting getting raped by the opaqueness of any modern C Toolchain.
Having you do bitch work isn't hiding shit from you in the slightest, if anything it further adds to the opaqueness of the code since you can't fundamentally understand it by tracing types and being safe in knowing that the compiler's concepts of runtime cannot be violated purely by chance.
Joshua Young
Boy, you're fucking stupid.
Jason Scott
>yet another no argument C babby.
yikes. 2 in one thread.
Carter Bailey
>C sucks The words of a programming noob that doesn't know shit.
>C is fine but I'd rather use [other language] because it's easier for me/I like its features/etc Great
>C is best, I use it over everything else Also great.
Shut your mouths, amateurs, and learn what C is about, then use your Python or Rust or whatever. Or maybe you'll figure out how great C is and just use it. Either way, better than your immature, uneducated, shit attitude.
Jonathan Morgan
>such as "optimizing out" what is assumed useless code If the code is actually unused, the program logic is the same optimizations or not. But I assume you're referring to instances like the compiler optimizing out a null pointer check, in which case the pointer was dereferenced somewhere else and the compiler assumed it could never be NULL.
Xavier Mitchell
>leave it to the programmer Haha, I fucking wish. That sort of library is dead simple to adapt - just slap smartpointer newtypes on everything and call it a day
libwayland-server owns all the major objects and manages their lifecycles internally. You only get to register some callbacks and tell it when to run its event loop. I forget the details of the problem (this was 4-5 years ago), but the basic idea was that there were two different code paths (one for handling external events from clients, and one for internally-generated events that require messages to be sent out asynchronously) that both needed to mutate/deallocate objects and that interacted with each other in complicated ways.
Jonathan Reyes
>runtime expectations that's the point, dumbass. C has no runtime expectation of there being a heap at all.
Oliver Parker
neither does rust?
memsets that wipe out sensitive data for instance can be optimized out.
Aiden Gomez
That's only true for freestanding C. Sure, it'd be possible to create a C standard library that just has malloc always return NULL, but that's not a useful library that people are going to want to use.
Alexander Ramirez
I said the LANGUAGE. Obviously the standard library for an OS assumes there's a heap, but the language's syntax, and none of its fundamentals, care whether there's a heap. C is still C without malloc.
Dominic Sullivan
Ok, I didn't get that from your original post. The standard name for it is "freestanding" vs "hosted" C.
>11k lines for some FFI >macro hell with pages and pages of comments to explain what's going on in generated code >all this just to wrap an API that responds to asynchronous messages and syncs server state
I nope'd the fuck out of rust a couple years ago when I saw nobody had any reasonable answer to these issues.
If you aren't writing an implementation of CSS or SVG or something then Mozilla just doesn't care about your use case.
Isaiah Johnson
Drew is a massive faggot that can only make angry blog posts about how evil Nvidia is.
Levi Rivera
>Defending nvidia Imagine being this much of a cuck.
Kevin Wright
Everyone should hate Nvidia.
Adam Richardson
Nvidia is fucking awesome
i like to suck its jimmis from its willies everyday
Xavier Thompson
This literally would have been orders of magnitude less code, and less work, if he'd just frosted butts
David Stewart
Well, your problem there is C++. If you make a language so complex that not even its creators know 100% of the language, then have people writing libraries each using their preferred 10% of the language, and all of these features have complex interaction, of course everything gets fouled up.
