100%. I've always used youtube on desktop (connected to the TV usually), and it seems to me they're just making all versions of youtube into a mobile app optimized for shorts type content. Recommendations are hugely influenced by what you watched very recently. What used to be related videos in the side panel of the player is now just the home page again, but vertical. Even just generating a recommendation from "Whatever (part 2)" to "Whatever (part 3)" is hit or miss now. Some of the recommendations are actually quite good, but at least for the way I like to watch, it's only getting worse over time. The category labels on the home page are also pretty telling - horrible labels (e.g. I watch some cooking/recipe videos and the label will be "Baking sheets" or something like that), plus it emphasizes the recency bias when it shows 5 categories that are basically just the same content with different labels and forgets what I've always liked watching.
> Recommendations are hugely influenced by what you watched very recently.
Ah, well, I don't know that I fully agree.
I watch channels that are people building things, repairing tools, or goofing around in an easy-going way without a lot of product placement or sponsored content.
And yet, all of the recommendations I get are either sponsored unboxing videos with AI voiceovers or click-baity channels with ugly reaction faces in the video thumbnails. I guess those probably make more money for Google.
I suspect ad revenue isn't good for maker/hacker type videos. I watch a lot of woodworking and cnc projects, and I mostly get the kind of recommendations you're talking about
For me my home page is now 95% videos I've already watched. The side bar is the only reliable source of new content. Until recently I had no subscriptions but that never used to matter. I had to subscribe to Patrick Boyle in solidarity when they demonetized his Epstein video.
Genuine question, but have you seen the popup being described? It's absolutely huge, and has a fake x button pattern. The complaint is on how disruptive it is, not the ask for donations
I don't think this applies to Python. There is a core team and there are expenses, but people do contribute code and work. Not to mention corporate sponsors. Sure, donate if you want, but it's not the same as blocking ads on purely ad-funded content (which I do, but won't defend as much)
I looked out of curiosity and on my 15 inch laptop screen it does take up probably about 40%. I'm surprised by how egregious it is. And it looks like they changed it (or there's an A/B test?) since the thread. It also now jokes about how banners are cringe, actually taking up more space!
I'm definitely in favor of not pessimizing code and assuming you can just hotspot optimize later, but I would say to avoid reusing objects and using sync.pool if it's really not necessary. Go doesn't provide any protections around this, so it does increase the chance of bugs, even if it's not too difficult to do right.
I mean, do it if it's worth it. But the parent seemed to imply everyone should be doing this kind of thing. Engineering is about tradeoffs, and sometimes the best tradeoff is to keep it simple.
Your initial judgement of using sync.Pool is quite overboard. The average go dev would wind up goroutines without much thought and pull in mutexes to avoid trouble. That's a hard thing to manage, using sync.Pool is comparatively easy.
For me it looks like the general sentiment is that go enabled concurrency, which should be leveraged, it also did simplify memory management, which should be ignored. But memory management has an direct impact on latency and throughput, to simply ignore it is like enabling concurrency just because someone said it's cool.
Yeah, golang is a particular nightmare for SIMD. You have to write plan 9 assembly, look up what they renamed every instruction to, and then sometimes find that the compiler doesn't actually support that instruction, even though it's part of an ISA they broadly support. Go assembly functions are also not allowed to use the register-based calling convention, so all arguments are passed on the stack, and the compiler will never inline it. So without compiler support I don't believe there's any way to do something like intrinsics even. Fortunately compiler support for intrinsics seems to be on its way! https://github.com/golang/go/issues/73787
> Go assembly functions are also not allowed to use the register-based calling convention, so all arguments are passed on the stack, and the compiler will never inline it.
Even if you had access to the register convention (which you kind of do), would it be of any benefit? The registers in question are general-purpose registers, not vector registers.
You're both stating things that are a bit beside the point.
Pure Go code uses registers to pass function arguments whenever possible. Large structs and/or numerous arguments can still spill onto the stack, though.
FFI (cgo) uses whatever the platform's calling convention requires. These conventions also usually favor registers.
Go has its own assembly language, which is neither of those two things. Go assembly technically supports two ABIs, one called "ABI0" and the other called "ABIInternal" [1]. The former passes all arguments on the stack and is stable while the latter passes some arguments through registers but is unstable and subject to change. Accordingly, people writing Go code outside of the Go toolchain almost always use ABI0, so that the code keeps working even when new versions of Go are released.
> Henriks true penalty would be living in a country of 6 million people that all know his face and that he is a pedophile.
This is what I object to, not really your comment. Is this factored into the sentencing? If he weren't a public figure would he have a harsher sentence?
> You don’t have to worry about him doing anything in Politics again
Sure, if everyone in Denmark remembers this guy then he won't be popular. But really we don't have to worry about him? 4 months later is he just free to go back to collecting CP, maybe leave Denmark, etc?
JPEG is similar actually. The DCT is invertible, but the result of the DCT is quantized, which is where some of the compression happens (DCT -> quantization -> IDCT), so the end to end process is not truly invertible. Maybe an analogy to the non-linearities in between the linear steps in deep learning
reply