We'd need a quantum leap in storage and bandwidth first - orders of magnitude better, if we want competing to be financially sane 😮💨
Maybe when Google is (hopefully eventually) shattered into a million pieces by some US judge, YouTube could be splintered into several smaller companies, each with some portion of the infrastructure and channels/videos - thus forcing competition. Vaguely similar to the Bell divestiture.
I'm not well versed in the machinations of the Chinese government, but if a relatively "normie" VPN like Nord works in China... it's probably controlled opposition (i.e. they're logging everything to a government server.)
I understand the sentiment, but... HTML and some light CSS is just as fast and much more accessible. It just strikes me as something that defines itself in opposition to "thing everyone uses" for no good reason.
A large language model has no concept of good or bad, and it has no logic.
Tragically, this seems to be the minority viewpoint - at least among CS students. A lot of my peers seem to have convinced themselves that the hallucination machines are intelligent... even when it vomits unsound garbage into their lap.
This is made worse by the fact that most of our work is simple and/or derivative enough for $MODEL to usually give the right answer, which reinforces the majority "thinking machine" viewpoint - while in reality, generating an implementation of & using only ~ and | is hardly an Earth-shattering accomplishment.
And yes, it screws them academically. It doesn't take a genius to connect the dots when the professor who encourages Copilot use has a sub-50% test average.
My guy, see a doctor. Temporary blindness/blacking out is not a normal reaction to nicotine, even in excess. "Nic sick" should just mean nausea/vomiting, dizziness and headaches.
A few posters I bought from the campus poster sale at the start of the year. (Specifically, a woodblock print, a solar system map and a Cowboy Bebop poster.)
I have a huge window with a nice view (in a university owned apartment no less!) so I can afford to skimp on the other walls.
At least five years. Even if the company goes under tomorrow, it'll be a while before the mainboard is truly obsolete. The main "consumable" would be the battery, which I can probably hack a replacement for if official parts are no longer available.
I've had mine (first generation 13" model) for over a year now. I'm very happy with it, and I intend to make it last me through university (3 years) and then some. I would consider it a good investment for me.
Well, that's to be expected - the implementation of map expects a function that takes ownership of its inputs, so you get a type mismatch.
If you really want to golf things, you can tack your own map_ref (and friends) onto the Iterator trait. It's not very useful - the output can't reference the input - but it's possible!
I imagine you could possibly extend this to a combinator that returns a tuple of (Input, ref_map'd output) to get around that limitation, although I can't think of any cases where that would actually be useful.
It wouldn't be as relevant, since passing a function or method instead of a closure is much easier in Rust - you can just name it, while Ruby requires you to use the method method.
So instead of .map(|res| res.unwrap()) you can do .map(Result::unwrap) and it'll Just Work™.
> online gambling
Cry harder