Somehow, it feels like the fields are larger on average, even though this is clearly not the case…
Somehow, it feels like the fields are larger on average, even though this is clearly not the case…
A few years ago, all the languages I would use started to have automatic unused variable warnings built-in. And yeah, by now when I hear of people that don’t have that, it’s very much a feeling of “Man, you live like this?”.
Not if you never get your application into production…
I wish this was as much of a joke as I’m pretending. It’s so common for software projects to get cancelled that lots of tooling differences are just in terms of how long they let you not deal with long-term problems and how violently they do then explode into your face.
For most of the development lifecycle of a GCed project, you’re gonna ignore memory usage. And if you’re lucky, it can be ‘solved’ by just plonking down a thiccer piece of hardware…
I mean, he did fuck up a good chunk of everything…
Ah, interesting. I went from garbage-collected languages where thinking about ownership might be useful for keeping complexity low and occasionally comes up when you manage lists of objects, but ultimately isn’t needed, to Rust where well-defined ownership is enforced by the language.
So, I wasn’t aware that ownership is even as concrete of a thing in other languages…
Geht eher darum, dass er sich dabei benimmt als wäre er der Geilste, obwohl er eben explizit nur der Drittgeilste ist. Z.B. tut er ja auch so, als würde er mit dem Biss prüfen, ob seine Medaille aus echtem Gold ist, obwohl es vermutlich nur eine Bronzemedaille ist…
At first I thought, this was the same beats, just with staggered emphasis, but no, that’s 30 eighths in the timespan of 14 eighths.
So, it’s like the bassoons are playing sixteenth notes, except that they’re decidedly not in sync with everyone else.
At first it’ll sound like they’re too early. Then their offbeat sixteenth will sync up with the on-beat for everyone else. Then their offbeat will sound like it’s too early compared to the on-beat, until they sync up properly again. Well, and then you do that cycle a second time, because they have to fit two extra notes in there.
Yeah, that does seem quite impossible to conduct, but even if you set up two metronomes, that’ll throw even good orchestras quite easily…
KDE Discover and GNOME Software can install from FlatHub (or other Flatpak repos, if you add those).
Hmm, not sure, if I’ve heard of it. I’m guessing, we’re not talking about simply drawing a UML class diagram…? Is it for figuring out which object will have to clean up which other objects, in non-GCed languages?
Wundert mich, dass sie nicht gleich einen vollwertigen Grünstreifen anlegen. Da würden sich auch Bestäuber wohlfühlen, und so mancher Vogel würde im Frühjahr dort ein Nest bauen und dann im Sommer Schädlinge wegsnacken…
The last one seems to be mostly like Brainfuck, just with different capitalizations of “moo”: https://esolangs.org/wiki/COW
Yeah, these become a lot less relevant with routine.
Avoiding the main-thread panicking is mostly just a matter of not using .unwrap()
and .expect()
.
String
vs. &str
can mostly be solved by generally using owned datatypes (String
) for storing in structs and using references (&str
) for passing into function parameters. It does still happen that you forget the &
at times, but that’s then trivial to solve (by just adding the &
).
“temporary value dropped while borrowed” can generally be avoided by not passing references outside of your scope/function. You want to pass the owned value outside. Clone, if you have to.
“missing lifetime specifier” is also largely solved by not storing references in structs.
The thing with OOP, particularly how it’s used in GCed languages, is that it’s all about handing references out to wherever and then dealing with the complexity of not knowing who has access to your fields via getters & setters, or by cloning memory whenever it’s modified in asynchronous code.
Rust has quite the opposite mindset. It’s all about tracking where references go. It pushes your code to be very tree-shaped, i.e. references typically¹ only exist between a function and the functions it calls underneath. This is what allows asynchronous code to be safe in Rust, and I would also argue that the tree shape makes code easier to understand, too.
But yeah, some of the patterns you might know from OOP will not work in Rust for that reason. You will likely need to get into a different mindset over time.
Also just in case: We are talking OOP in the sense of the paradigm, i.e. object-oriented.
Just using objects, i.e. data with associated functions/methods, that works completely normal in Rust.
¹) If you genuinely need references that reach outside the tree shape, which is mostly going to be the case, if you work with multiple threads, then you can do so by wrapping your data structures in Arc<Mutex<_>>
or similar. But yeah, when learning, you should try to solve your problems without these. Most programs don’t need them.
Yeah, we onboarded some folks into a Rust project last year and a few months in, they were genuinely surprised when I told them that unwrapping is pretty bad. Granted, they probably did read about it at some point and just forgot, but that isn’t helped by lots of code using .unwrap()
either.
Can still use .is_positive()
, though…
Yeah, you understood my comment entirely the wrong way around. When I say “dotfiles”, I mean the non-Nix way of managing application configurations. Nix Home-Manager happens to write to these dotfiles, but that means I don’t have to deal with the dotfiles myself.
I feel like setting up a new machine is just the easiest to explain.
Personally, I find dotfiles messy, as you often just want to change one or two settings, but you always carry along the whole file with all kinds of irrelevant other settings. This also makes it impractical to diff two versions of those dotfiles, especially when programs write semi-permanent settings into there.
I guess, your mileage will vary depending on what programs or desktop environment you use.
For example, I love KDE, but they really don’t do a good job keeping the config files clean. Nix Plasma-Manager generally fixes that, and for example allows defining the contents of the panel in a readable form.
I feel like it’s just capitalism doing a capitalism. People are self-conscious about their skin, so you can sell them all kinds of crap.
Even a basic washcloth does a decent job with exfoliating, if you use it regularly. Rub your face dry with a scruffy towel, if you need more than that.
But of course, there’s hardly any money to be made with reasonably priced products, so you won’t see TV ads for them.