Yeah, I'm really wondering why they thought this was a good idea. My best guess is that they want to keep everything within one file, since it makes the script easier to deal with. But when automation actually starts being implemented, they want the functions for each task to be grouped (and I believe, Python doesn't support inline modules), so they abuse classes for that...?
Well, and I guess, it allows them to have pseudo-constants within each task, which don't need to be explicitly passed around between functions.
But yeah, really not a fan of needing this much boilerplate to start out with. In my opinion, the activation energy required to use this pattern instead of slapping down documentation needs to be as minimal as possible, otherwise folks will slap down documentation instead.
I would very much argue that you shouldn't add complexity unless you actually make us of it. Them all using a uniform structure doesn't help readability nearly as much as just not having the complexity...
I still hope for it to flip back eventually. You need gamers to be gaming on Linux for them to eventually dip into gamedev on Linux. When that happens, they're definitely not going to develop for Windows first and use Proton to make it work on their system. Of course, yes, this may take a long time to actually happen.
I don't believe, Zig provides much in terms of safety? To my knowledge, it uses manual memory management à la C, just being less horrid in some aspects, like using an option type instead of null pointers.
You might want to ease up on the conspiracy theories. I'm not part of some irustinati that wants to force everyone to use Rust and nothing else. I was merely describing what I believe to be reality. In fact, I expect the strongest opposition to a third language will come again from those who've been coding nothing but C for the past decades.
I really don't see why they should feel obliged to include another language, just because they included Rust. There is no fairness guarantee or whatever. If anything, Rust now fills the memory safety and modern language gap, so there is much less of a need to include another language.
I'm just talking about things like async closures looking like they might be really useful in a frontend framework we use. And I'm wondering when that framework's documentation will recommend their usage. Or if there's fancy things they can do with the AsyncFn traits.
I will have to try out, if I can just pass an async closure without that framework changing anything. That's the kind of thing where I am still unclear, how it will affect things. But the basic premise of editions isn't lost on me, and this isn't my first edition switchover either.
To point it out for folks unfamiliar with Rust, I consider this comment borderline misinformation.
I don't know in what world the Rust compiler is considered unreliable. In my experience, it is one of the most reliable toolchains across all programming languages.
The Rust compiler is slow, because it does so many more checks than the C compiler, which is what these devs want. This is also barely relevant while actually developing, because then incremental compilation kicks in, which makes subsequent builds rather quick.
And Rust binaries are primarily larger than C binaries, because it does not use dynamic linking of dependencies. In the kernel, you cannot use dynamic linking anyways, because you need a running kernel to have a filesystem from which to dynamically load these.
Yeah, fair enough. I was mainly curious, how much would break, as in how quickly I might expect the Rust ecosystem to adopt these new features. Well, and unless there's a reason against it, I'd prefer having everything on the same edition, i.e. the newest edition.
You very likely want KDE. It's got the most features out of the box, each of which is something you can customize (whether you want it enabled and with what behaviour).
There's arguments to be made that more minimal desktops, like Xfce, or even a DIY setup using a window manager, are simpler to customize, because they have fewer features.
For example, the panel theme in KDE involves various colors and icons and whatnot, so you need a full-fledged theme package to customize it, even if you 'just' want to change the panel color. In Xfce, the panel color is a simple hex value that you can just set.
GNOME is a weird one. It also has relatively many features, so it does still have relatively many options. Some configurations are relegated behind extensions or a separate settings program (GNOME Tweak Tool). And yes, you can technically apply CSS. But then for some relatively basic things, you need to dip into CSS or other workarounds.
I don't know, if it's still the case, but a few years ago, I just wanted my windows to not have a titlebar, which took me three days to figure out how to do, eventually solving it with CSS.
A few months later, I switched to KDE and there it can be done with a GUI setting, which took me less than ten minutes to figure out.
Just upgraded ten or so smaller projects with no compile errors whatsoever. And then one larger project (probably 20k lines of code or so), which just had a few calls to env::set_var() that needed to be wrapped in unsafe, as well as some uses of ref in pattern-matching, which were apparently not needed, so I'm actually glad to be rid of those.
Very happy with that overall. I was already worried, they might introduce too many breaking changes with how long they were working on this edition, but those worries just evaporated.
Honestly, kind of most excited about std::env::home_dir() being fixed/undeprecated. That's the kind of thing that some languages would leave unfixed for eternity, until half the community recommends not using the stdlib even for basic uses.
Yeah, fair point. It doesn't make it impossible for a manager to decide to downsize the studio after a launch, but at the very least, you won't draw as much attention to that being an option, when you don't need to pitch a new project while you're about to run out of things to do.
The problem is that even when a studio publishes a successful game which brings in sales over many months, you can still generally reduce short-term costs by firing those devs. And investors love short-term profits.
Linus has also declared Rust as basically inevitable before, since more and more kernel maintainers retire and not many young devs learn C anymore, at least not to a proficiency where you can handle kernel development.
I plan to hold a relatively informal talk about declarative macros in Rust at $DAYJOB and the colleague who organizes that used an LLM to write the invitation flavor text.
I don't hate it for that. It does some text formatting with emojis and whatnot, which is decent enough. It does have information about declarative macros, so it can throw in some rough ideas what listeners can expect, like reduced boilerplate.
What I certainly like less is that it sounds like the most bombastic salesperson, and of course doesn't know what my talk will actually be about, so it just promises everything.
Including some straight-up non-sense, like apparently I'll show folks how to use declarative macros to "improve performance". That genuinely had us wondering, if that's possible. I'm guessing, you could theoretically pre-compute a value at compile-time, but them being declarative macros, you'd have to do horrid constructs, like basic addition becomes the equivalent of if a==3 && b==5 then 8. I will most definitely not show that.
My best guess is that it saw that it's about Rust, so it just threw in "performance" somewhere. 🫠
Well, and of course, it repeats itself and writes lots of empty phrases. The text for the invitation is almost as long as my notes for the talk...
Yeah, I'm really wondering why they thought this was a good idea. My best guess is that they want to keep everything within one file, since it makes the script easier to deal with. But when automation actually starts being implemented, they want the functions for each task to be grouped (and I believe, Python doesn't support inline modules), so they
abuse classes for that...?Well, and I guess, it allows them to have pseudo-constants within each task, which don't need to be explicitly passed around between functions.
But yeah, really not a fan of needing this much boilerplate to start out with. In my opinion, the activation energy required to use this pattern instead of slapping down documentation needs to be as minimal as possible, otherwise folks will slap down documentation instead.