Before there was python, before there was node, there was perl. It's old, it's crufty, it's a product of a bygone age, but even today if you want to do something with regular expressions and ingesting text it's still one of the easiest options. Of course it's highly debatable if you should ever use regex to ingest text.
orclev
joined 1 year ago
If the law was changed in such a way that it only ever applied to a specific person sure, but changing laws after someone does something is kind of the way things work. Somebody does a thing, everyone goes "I can't believe they did that, there should be a law against it" and then a law gets passed or amended. Is that law targeting that specific person at that point? Kind of, in that the actions of that person prompted the change, but it would have been the same if a different person had done the same thing.
I really want to see what these numbers look like on the 1st after all the 3rd party clients are dead. Presumably that will also kill most of the bots as well. I suspect the numbers don't look worse because a significant chunk of the post and comment traffic is automated which will stop working at the end of the month.
Automatic upvote for the Niven reference. I don't think anything would stop Trump from grifting money from his supporters. It's like the kobayashi maru, the only options are the least bad ones.
In this case I think they've opted to split the difference and take a mugshot proving he's still being treated like a criminal (although it would have been better to have forced him to wear handcuffs), but not release it to deny him as much free fundraising fodder as they can.
Ultimately as you point out it won't really matter, they'll just photoshop something, but at least this way someone will need to put in the effort to make the image and we'll all get some entertainment about how horrendous of a job they'll inevitably do.
One of the advantages of federation is that content can be distributed but still accessible, so on the one hand it doesn't really matter that there are three (actually more than that) rust communities on lemmy. On the other hand it can be confusing for newcomers and introduces a discoverability problem.
The factors I'd look at are how reliable is this instance, how well moderated is this instance, and lastly what are the rules of this instance.
On the first point lemmy.ml loses some points. It's heavily trafficed and struggling at the moment under that load. lemmyrs.org on the other hand is pretty new and low volume but so far seems stable. I can't speak to programming.dev because I didn't even know that instance existed until I saw this post.
On the second point I'm not sure there's enough data to go on other than to say that the main reason the quality of moderation matters is because a poorly moderated or controversial instance is likely to be defederated from other instances. While lemmy.ml is a fairly lightly moderated instance its importance as one of the founding and largest instances means it's unlikely to be defederated.
On the third point it seems like lemmyrs.org would have the least friction with the Rust community since it's ostensibly dedicated to said community and therefore should have no reason not to enforce the CoC of the community. I'm not sure what the rules of programming.dev are. lemmy.ml on the other hand has a fairly modest set of site wide rules. The rust communities would be free to enact more restrictive sets of rules however so ultimately as long as the rules of the instance aren't felt to be too restrictive by the community I'm not sure it actually matters.
Ultimately I think what will become the Rust lemmy community will likely come down to whichever one eventually gets the blessing of the larger Rust community. Once it's listed somewhere in the main Rust sites that will then be where everyone will gravitate towards. Until then just subscribe to all of them.
Pretty much anything is going to be a softer introduction than Haskell, it's like the black diamond level course of strong typing and functional programming. That said learning it fundamentally shifted the way I think about programming in what I consider to be a good way.
With Haskell, when you finally manage to get your code to compile without error, it will usually work and be bug free. The reason for that is that its type system and the constraints of its functional language design have forced you to really sit down and think about exactly how your code is going to react to every possible situation. Rust is similar but provides a lot more lazy options for you. For instance if you really don't care if your code crashes at some particular point you can just slap .unwrap() on something and call it a day. That's basically telling the compiler "I either don't expect this to error, or if it does error I just don't care, kill the program and call it a day". This is in contrast to Haskell that would have forced you to explicitly handle the various error conditions and explicitly opt into killing your program at that point. In either case though the fact that something has returned a Result wrapped value (or the Haskell equivalent of Either) has explicitly forced you to think about the fact that whatever returned that value might have produced an error instead and what you want to do in that situation.
Having to actually think about errors and how to react to them is a massive win for writing correct and bug free programs. Other languages let you just assume that everything is going to work, but there are all these places that errors can occur but often don't so you get in the habit of thinking as if errors can't occur there, then when they do it's always a shock. C is particularly bad about this because there's all kind of places where C functions return garbage results and you only know they're garbage if you check the global error variable, which you totally remembered to do right?
I guess the point I'm trying to make in a roundabout fashion is that Rust somewhat, and Haskell definitely, force you to spend a lot longer writing your code in the first place because you need to put some thought into how the code will react to various situations in an imperfect world where various things just don't work like they should, but the end result is code that lacks surprises. It's always going to behave like you expected it would (assuming your understanding of whatever algorithm or business rule you're implementing is correct) which ultimately saves a ton of time debugging. Having a compiler error that points you at a particular line of offending code with a (hopefully) clear explanation of why that particular line is problematic is so much simpler to deal with than a cryptic error message at runtime that could be coming from a barely even related part of the code due to a whole series of assumptions having failed in the face of one unhandled error state.
Looking at your languages listed what strikes me is that none of them are statically typed (C arguably is, but C barely even has a type system by modern standards). I suspect that's really what you're struggling with. Added to that is that the Rust type system is heavily inspired by Haskell, and OCaml which are quite unlike most other languages.
My primary language I get paid to work in is Java, but I also had extensive experience in Haskell prior to tackling Rust so my biggest hurdle was just altering the way I thought about variable scope and ownership.
Something very important that fundamentally shifted how I think about programming that I learned while studying Haskell is to think about types and transformation. Types are representation of State, and a program is just a current state and a series of transformations applied to it. Advice that is often given in the Haskell community and which largely applies for Rust as well is to follow the types.
That's probably why I like Rust so much. I've felt for a long time now that after the concept of null, the widespread embrace of OO is probably the second worst decision in programming. While it was certainly better than the goto hell that preceded it, inheritance I think has ultimately proven to be a trap.