If Rust has one weakness right now, it's bindings to system and hardware libraries. There's a massive barrier in Rust communicating with the outside ecosystem that's written in C. The definitive choice to use Rust and an existing Wayland abstraction library narrows their options down to either creating bindings of their own, or using smithay, the brand new Rust/Wayland library written for the Cosmic desktop compositor. I won't go into details, but Cosmic is still very much in beta.
It would have been much easier and cost-effective to use wlroots, which has a solid base and has ironed out a lot of problems. On the other hand, Cosmic devs are actively working on it, and I can see it getting better gradually, so you get some indirect manpower for free.
I applaud the choice to not make another core Wayland implementation. We now have Gnome, Plasma, wlroots, weston, and smithay as completely separate entities. Dealing with low-level graphics is an extremely difficult topic, and every implementor encounters the same problems and has to come up with independent solutions. There's so much duplicated effort. I don't think people getting into it realize how deceptively complex and how many edge-cases low-level graphics entails.
> using smithay, the brand new Rust/Wayland library
Fun fact: smithay is older than wlroots, if you go by commit history (January 2017 vs. April 2017).
> It would have been much easier and cost-effective to use wlroots
As a 25+ year C developer, and a ~7-year Rust developer, I am very confident that any boost I'd get from using wlroots over smithay would be more than negated by debugging memory management and ownership issues. And while wlroots is more batteries-included than smithay, already I'm finding that not to be much of a problem, given that I decided to base xfwl4 on smithay's example compositor, and not write one completely from scratch.
Thanks for the extra info. I'm glad it hasn't turned out to be much of an issue. I've looked at your repository and it seems to be off to a great start.
Personally, I'm anxious to do some bigger rust projects, but I'm usually put off by the lack of decent bindings in my particular target area. It's getting better, and I'm sure with some time the options will fill out more.
There really isn't a "massive barrier" to FFI. Autogenerate the C bindings and you're done. You don't have to wrap it in a safe abstraction, and imo you shouldn't.
This. It is somewhat disheartening to hear the whole interop-with-C with Rust being an insurmountable problem. Keeping the whole “it’s funded by the Government/Google etc” nonsense aside: I personally wish that at least a feeble attempt would be made to actually use the FFI capabilities that Rust and its ecosystem has before folks form an opinion. Personally - and I’m not ashamed to state that I’m an early adopter of the language - it’s very good. Please consider that the Linux kernel project, Google, Microsoft etc went down the Rust path not on a whim but after careful analysis of the pros and cons. The pros won out.
> This. It is somewhat disheartening to hear the whole interop-with-C with Rust being an insurmountable problem.
I have done it and it left a bad taste in my mouth. Once you're doing interop with C you're just writing C with Rust syntax topped off with a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer. It's unergonomic and you lose the differentiating features of Rust. Writing safe bindings is painful, and using community written ones tends to pull in dozens of dependencies. If you're interfacing a C library and want some extra features there are many languages that care far more about the developer experience than Rust.
> a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer
You just have to get over that. `unsafe` means "compiler cannot prove this to be safe." FFI is unsafe because the compiler can't see past it.
> Once you're doing interop with C you're just writing C with Rust syntax
Just like C++, or go, or anything else. You can choose to wrap it, but that's just indirection for no value imo. I honestly hate seeing C APIs wrapped with "high level" bindings in C++ for the same reason I hate seeing them in Rust. The docs/errors/usage are all in terms of the C API and in my code I want to see something that matches the docs, so it should be "C in syntax of $language".
> a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer
That's bizarrely emotional. It's a language feature that allows you to do things the compiler would normally forbid you from doing. It's there because it's sometimes necessary or expedient to do those things.
My point is that using C FFI is "the things the compiler would normally forbid you from doing" so if that's a major portion of your program then you're better off picking a different language. I don't dislike rust, but it's not the right tool for any project that relies heavily on C libraries.
C++ was the GUI king during the 1990's, and none of the Rust toolkits is half as good as the surviving frameworks, like C++ Builder, Qt, wxWidgets, heck even MFC has better tooling.
Trying to defer to native widget rendering per platform was a mistake, and every time I've touched wxWidgets in the past decade and a half I've regretted it.
FLTK on the other hand is ugly as sin, but I've found it reliable enough to not act in surprising ways, and it's also small enough to where you can vendor it and build it alongside your program.
HFCS came about when there was an abundance of corn and nothing to do with it. So when they discovered corn syrup they added corn subsidies and heavily tariffed cane sugar. Ethanol appeared and is a far greater corn sink, so HFCS no longer even serves that purpose.
But the processing industry doesn't want to disappear (money and job losses), so they lobby and the status quo remains. Same with private health care in a cozy position where they act as an unneeded middleman. It's too lucrative to certain people, and they won't willingly give it up.
My understanding was that the meat-packing process in the US involves a butchering method that results in more fecal matter contamination, posing the risk of salmonella, which necessitates the wash. Those bacteria occur naturally, so you can't avoid that without being careful with butchering, which is probably what the EU standards require. But I doubt the big meat conglomerates like Tyson will want any hit to productivity, and they would fight a change every step of the way.
Mechanically separated meat bluntly ruptures the digestive tract and smears the flesh with feces. So they soak the feces and flesh together in a chlorine or acid bath to sanitize it. It's disgusting.
They, and everyone at the time, were kind of forced to switch to lead-free solder by RoHS. At that point, there probably hadn't yet been tests showing the results of constant thermal cycling, so the brittling effect was unknown. Apple was particularly affected as an early adopter because of their PR stance on environmental issues.
Refusing to acknowledge anything was wrong was the real problem. But that's just a reminder that companies don't care about you. Brand loyalty is a quagmire.
This guy is one of the top names in AI. This is pure propaganda written to instill "fear of missing out" and encouraging people to buy into his platform, lest they become "obsolete."
It’s a little shocking to me that this sentiment hasn’t floated higher in the discussion. Regardless of how he feels, this is the way he wants you to feel.
Big picture it’s about emotional intelligence and if you are losing your shit you’re going to flail around. I think you should pick up some near-frontier tools and use them to improve your usual process, always keeping your feet on the ground. “Vibe coding” was always about getting you and keeping you over your head. Resist it!
given that the 3 hares seem to currently lack a signification, I'd be up for squatting? Or would Paul prefer 3 fennecs? Should anyone wish to oppose us, as Bigwig said: "silflay hraka, u embleer rah"
a slightly more pragmatic story for shunya as better mousetrap: just as we now routinely have our calculations done for us in binary, but record results in decimal (in PDF invoices, say), ancient romans (among other cultures) would have someone do their calculations on a counting https://en.wikipedia.org/wiki/Counting_board board, but recorded (only the non-zero) results in roman numerals.
(these days we can spot the algebraists via a sibboleth: they start their papers and books with section/chapter 0)
> « Les hommes sont comme les chiffres : ils n'acquièrent de valeur que par leur position. » —NB
To be fair I did have just a touch of thought disorder which led me to write "vive" instead of "vibe" and I did correct it when it was pointed out without explaining it which made that comment seem even weirder than it originally was.
I actually read their comment as "vibe vibe live" which combined with the unknown terms in the next line (a reference to Dune combined with something else, I guess?) made GGP's question fit quite well.
on the other hand, it does currently feel like when angular and react were starting to come out, and there was a billion different javascript libraries to learn with a new one coming out every couple weeks, and you arent quite sure what you should spend your time on and how much, vs now where you just learn react, and maybe extend to next.js
LLM forward development has a lot of things going on, and it really isn't clear yet what is going be the common standard in a few years time in terms of dev ux, async tools, ci/cd tools, in production and offline workflows, etc.
its an easy time to hop down a wrong path picking subpar tools or not experimenting further, but if you just wait, the people who try the right tools are going to be way ahead on making products for their customers.
Uncharitable take.
His last public stance on this a few months ago when he released nanochat was that he didn’t use coding LLM for it, even though he tried, because they were not good enough and he was just losing time, so coded everything manually. Andrej is already set for life, and has moved into education where most of what he does is released for free.
Programmers aren't good at checking if the name is taken. We've done this particular one before. Phoenix (Firefox) had to change names because of Phoenix Technologies, then again because of the Borland Firebird Database.
That's the problem. Front-loading washers have generally been a terrible invention. Unbalancing and mold are among the widespread problems. The actually reliable washers are still top-load.
I've always wondered, since we only have front-load washers here in the UK, is there some sort of advantage to it, aside from space, which seems to be the obvious one, does gravity help with battering the clothes around when the drum spins slowly enough they can fall from the top of the drum?
Front loaders are gentler on clothes, use a lot less water, use a lot less energy, and spin faster in the spin cycle so there is less work for your dryer if you use one.
Top loaders are easier to load and unload, cheaper, and slightly easier to maintain.
With front loaders you should wipe the gasket after use because water left in its folds can promote mold and odors. With both you should leave the door open when not in use so air can circulate in the drum. With a front loader the open door can get in the way and is easier to accidentally close.
Interesting, thanks, I had no idea about much of this, I was aware of the door/mould thing, and stacking, though it's not something I've ever seen done here in the UK personally.
As a "typical" British household, we don't use a dryer, don't even own one in fact, we just hang our clothes to dry, which always struck me as ironic for such a humid, cold country, with smaller (than the US) homes and thus less space to hang stuff to dry.
It would have been much easier and cost-effective to use wlroots, which has a solid base and has ironed out a lot of problems. On the other hand, Cosmic devs are actively working on it, and I can see it getting better gradually, so you get some indirect manpower for free.
I applaud the choice to not make another core Wayland implementation. We now have Gnome, Plasma, wlroots, weston, and smithay as completely separate entities. Dealing with low-level graphics is an extremely difficult topic, and every implementor encounters the same problems and has to come up with independent solutions. There's so much duplicated effort. I don't think people getting into it realize how deceptively complex and how many edge-cases low-level graphics entails.
reply