drstats/export/posts-lorentz.txt

lorentz said I'm heading out right now among other winter cycling gear to buy a backup light,now the only risk is that I can't resist using my backup light to pretend that I'm a car,@retoor in the center. everywhere else there's light enough to tell where the road is supposed to be, but not to assert that it's actually a road and not a canal full of gravel with yellow-striped asphalt slabs resting on top,it'll be a hemisphere shaped hole by the time I realize,@retoor cross head refers to both Philips and Pozidriv in English and Hungarian,I manage my music with NewPipe and VLC. It's not flawless but I think it's a good failover if you're on Android.,@retoor nope, none of that, in fact I'm not even sure it has autoplay, just a queue where you can add songs from the "recommended" lists under existing songs. I don't mind that though, the YouTube algorithm has drains, bands and songs it keeps returning to within a given subgenre regardless of where you started, and I can only listen to so much Siames or Pomplamoose before I get tired.,correction, it does have autoplay, I just disabled it at some point,@retoor Well, they really don't have to do what they promise because they're Google. But I agree, their front-ends really are amazing for what they do (remove control from the user and then make acceptable choices so people don't miss that control),2fa should never allow access to anything in itself, only supplement other safe credentials.,@jestdotty TOTP doesn't expose any extra information to the service provider, is easier to implement, and harder to hack. Providers that only support SMS despite all these arguments are definitely fishing for phone numbers.,And then there's Microsoft Fucking Authenticator, which modifies _security policies_ on the phone where it's installed, but because it can't be used to contact me employers feel comfortable asking me to install it on my personal phone.,Every once in a while I spend 14 hours focused on a task and then realize at 10pm that I don't have anything to wear the next day. 4am sounds extreme though,@retoor Wow, I know some pretty extreme orthodox jews but none of them take issue with *others* working on Saturday, in fact they're very thankful if others take over any duties they may have. Sounds like a weird thing to ask of other people.,I guess this is what state-sanctioned religions are all about though, adding the given scriptures to the social contract.,I mean, libc is kind of a mediator between libraries and the OS,@Liebranca It would be nice if the C ABI was defined unambiguously for the major platforms.,god, how often I have to be that bitch,@retoor my give/recv ratio is atrocious though, I never remember to upvote even if I find a post interesting and spend tens of minutes talking under it.,@retoor I guess that's the benefit of the bigass like button Facebook pins to the top bar while scrolling comments.,what a daft argument, and how incredibly overused in spite of that!

You can make memory safe programs in Assembly too. You can make class hierarchies and interfaces in Assembly too. Why bother using another language?

Because the point of languages is what you CAN'T do, or more precisely, what has to be clearly marked. Memory safety doesn't mean "your programs can be memory safe". If it meant that, the entire infinite set of Turing-complete languages would be memory safe. Memory safety means that there CAN'T be a memory bug outside an unsafe block. ...,... It means that when your code gets reviewed by the 512'th time because someone somewhere in the ecosystem invited the NSA, Mossad and FSB into every Linux server in existence, the reviewers will not have to read all 100k lines of garbage business logic written by undergrads with zero job experience because they basically need half a career in their portfolio to even be considered for an unpaid internship, just those 30 lines of unsafe code where you implement a specific optimization you needed.,The point of Rust is that you don't have to be highly trained or vigilant, you can just write code. I agree that it's missing a ton of features and it's not really mature yet, even though "mature" is such a fuzzy term that there will be at least two decades between when I consider it mature and when C developers finally have to admit that it's as mature as any other lang, but the single benefit that I don't have to think about safety is important enough that it overrules any difficulty arising from the language's lack of maturity.,Ideally, the goal of C++ within the next 5 years should be to get to a point where an external safety investigator will be able to similarly skip over 99.9% of a C++ codebase which exclusively uses bounds checked access, ranges and smart pointers and simple cases of references and is therefore automatically verifiably lifetime safe, and manually prove the remaining 0.1%. They are making good progress by the way, I'm rooting for them, because the C++ type system is fantastic and I would really like to use it.,@Demolishun I think Herb Sutter charted a 10 year plan in 2019. I would never accuse Herb of having realistic ambitions, but I think that his grandiose plans can get people on board so I adopted that rhetoric. Also most of the external pressure for safety is coming from political entities which pretty much only communicate in the form of very optimistic plans. The NIST won't take "It'll be done when it'll be done" even though on some level they probably know that's the only real schedule.,@12bitfloat I don't think this is even close to Rust's final form. There are at least 4 major pending type system features that are waiting for the new trait solver which is slated to become generally available next year. Const is still kind of a pariah. FromResidual is technically viable now but we just can't agree on its semantics. That will affect almost every function in crates that takes a callback.,@12bitfloat But I guess you can chalk up all of that as library dev concerns. It's true that application development has been pretty much unchanged for a while.,@retoor The problem is manual lifetime management, the source of the majority of recorded critical security bugs. That's what smart pointers were built to replace, and that's why new is only marginally better than malloc.,@Demolishun Of course, you just gotta not make mistakes and then things won't go wrong! Why has no one ever thought of that?,in truth, to correctly model a time travel encounter you'd have to search the behaviour tree of the future persona for a sequence of actions that leads to itself, which is pretty much a whole state space search, so you'd need an ASI with exponentially more neurons than a human.,oh, I almost forgot:
Rehearsing social events dozens of times with digital twins of everyone present, thus creating and destroying countless groups of self-aware creatures on a whim, to ensure a desirable response from the one group you can't destroy without consequences.
SMBC reminded me about this one.,@donkulator I think even human intelligence is too much for that.,@donkulator Given how much of our lives is about getting laid, it's possible that we are in fact a Github action that futuristic humans use to verify that their dating app remains competitive in comparison to a few older reference apps.,@donkulator actually, near-future ML models should be more than capable of detecting bad UX by emulating the bottom 5% of user intelligence and attempting to run some tests purely from verbal description of the desired effect as part of a CI pipeline.,Pretty cool, but where does the flywheel go inside that thing? and what's its axis? Buses need kind of a lot of power and they tend to be moving very fast whenever the road is clear, the gyroscopic procession of a fully charged flywheel has got to be noticeable at least by the driver.,@Lensflare Actually, it may even be beneficial that way, it should keep the bus from falling over on very steep turns if it's ever taken off road (for not more than 10km),I can't think of a use case for a gyroscopically stabilized bus that wouldn't entirely exceed the operational range of a bus in the first place (for example, due to a lack of 3 point seatbelts), but I'm sure they exist. As for the flywheel, I'm not sure what a charger would look like but as far as physical limitations go it should be possible to charge it way faster than any battery, which is I think the limiting factor for charging battery-powered buses at stops.,@Demolishun I read about a concept for electric car infrastructure where the batteries themselves were rapidly replaceable. I sometimes wonder if a durable economic model could be designed for their distribution. Sadly batteries are expensive and degrade over time so if you want to replace one at a charging station they'd have to determine its quality before determining the differential price of the new fully charged battery.,Does the VS developer shell do something that a regular dev environment opened in a regular editor with a regular console doesn't?,@cuddlyogre Interesting, I never perceived envvars as such a complicated problem that OS config, a project-specific envfile, and build system scripting couldn't handle them completely.

I mean, there's only so many sources envvars can reasonably be associated with, mainly the code, the OS, and a finite number of modes to choose from.,If you lock the Mutex, any function that is called on the value should take a & or &mut depending on whether it itself mutates the value, and the guard should automatically decay to a reference as a result. If it doesn't, &*g or &mut*g should do the trick, as with any container that implements Deref,^ that isn't a logical law but it's ultra rare for a function definition to mention MutexGuard.,You mention the need to take an argument that may or may not be in a Mutex. Your main options here for parameter types are &T and &mut T, and when you lock the mutex the guard decays to either. If you need the function to take ownership of the value you're in a bit of trouble so consider thoroughly whether it really makes sense for that function to take ownership, and what the ownership means.

1. If you take ownership because you want to mutate the value long after even the caller returned, you should replace T with Arc<Mutex<T>>.

2. If the only reason you need to take ownership is because you're mapping over the value without copying, use a crate like replace_mut or take_mut.

3. If you take ownership because you expect the resources no longer to be available, you can use Arc::try_unwrap and Mutex::into_inner.,@jestdotty You can't dereference self? That's the first time I see that sentence, I dereference self all the time. A cursory search didn't bring up anything, and I tried to produce a few error messages too in case it's just an awkward templated message. Where did you read this?

std Mutex and async leads to unfixable deadlocks so I presume that's an async mutex from async_std or similar? Just checking.

Even still, can't you defer the actual assignment of the fields until after all the futures resolve so that you don't need to mutate the object in multiple places, especially during initialization? Having multiple unordered tasks write to the same object is exactly the kind of thing Rust discourages, and initialization is a special case where this really shouldn't be necessary because there is a return phase which is strictly ordered after all of the unordered setup tasks.,@CoreFusionX I really wonder what input redirection would look like in a structured shell. Maybe some function combinators?,@jestdotty It's late now but I'll fuck around with async tomorrow a bit because I'm beginning to suspect that your solution will actually be a

&Mutex<&mut T>

but I'm not sure how much of the usual reference stuff works in an async function and it bugs me that I don't know this. If you can't share the code, can you think of a minimal example that demonstrates the purpose and implementation of this async function?,@AdamOnAir All of those tools run just fine in the regular command line too, possibly with a $PATH extension. Why wouldn't they?,all I'm saying is, setting envvars is like the most fundamental thing you can do in a scriptable shell, more basic even than running other programs. It's not an IDE feature and tying it to one sounds backwards as hell.,@jestdotty Okay, I looked around, lifetimes work fine with async functions. The trouble is that the most obvious mechanisms of concurrency like tokio::spawn require their arguments to be 'static. There are other tools though. The type of my_mutex is Mutex<&mut Self>, and notice how the async blocks aren't move

https://gist.github.com/lbfalvy/...,If you do actually use Tokio specifically, tokio::join! does nearly the exact same thing. I picked futures because this can be implemented runtime-independently and you might be using a different runtime.,Also also, apparently futures also has an async mutex which would eliminate the async_std dependency, but I can't find one in Tokio, so I guess if you use Tokio it's better to use tokio::join and async_std's Mutex and eliminate futures? Idk, all of these crates also offer a ton of other overlapping features, pick whichever you like. Future is the glue and it''s defined in the standard library so pretty much all of these should just work together.,note: if you use the futures::future::join (or join3 etc) function instead of a macro, rust-analyzer won't be disabled inside the async blocks,@jestdotty Regarding deadlocks, are you absolutely sure that no future ever blocks the thread waiting for the result of another future, such as by receiving from a stdlib MPSC queue or locking an stdlib mutex?```