notheguyouthink

Good for you, but it's still optional for the right crowd. More specifically, you don't have to. Users can connect to your gaming group with zero friction. Not even signup! (at least, back in the day, i'm unsure what it's like not)

But even if you gave me a free mumble service, it still wouldn't be comparable to Discord - at least when i was using Discord.

The price wasn't the issue (imo), it was simply the user experience. It had the best, by leagues. Users (ie, non hosts) didn't pay for any of these products, but the UX of Discord was vastly superior in my view.

> Cross-breeding allows nature to combine things that fit together in all of the right place

I feel like this is putting too much faith in "natural" methodologies.

Eg, who's to say a cross breeding solution is less dangerous than a GM solution?

If the concern is that it may take 50 years to know the GM is bad, why are we assuming the non-GM is good now? You could say that people have been cross breading for many many generations, but i'm unsure why we'd know that one cross breed being safe means all crossbreeds are safe. I'm not inherently defending GM. I'm attacking the notion that man made tricks like cross breeding are inherently safe.

I disagree (to a degree). Everyone i know kicked and screamed about switching from Vent/Teamspeak/Mumble. I feel like it eventually dominated not because it was easy to dump existing solutions, but because existing solutions were poorly designed by comparison. No mobile, horrid chat, required install, poor voip quality. Discord came along with a better offering and it still was a tough switch.

With that said, i agree that no one "cares" about Discord. If a better thing comes along i could easily see people dumping it. But, i imagine it'll be a bit more difficult. Discord "won" in my view because it simply had to be modern to be vastly superior. However, i'm unsure how easy someone can make a next version that is such a superior leap.

Fwiw, as a gaming voip/chat i still find it a pretty great UX. My only complaint is that it is a bit laggy due to the, i assume, web-based interface on "desktop".

It is and it isn't. I imagine your humor implies that technical people are using Mastadon, ie the same type that would be using HN, but the reality is that while that is true, Twitter "rejects" are also using Mastadon. Sometimes this means communities filled with very.. controversial people.

> Currently the price is free, and comes bundled with uMatrix, and a cookie flush. I’d like to pay the NYT for their journalism, but only with money, not the ability to track me. As a result they get no money, and no tracking.

You misunderstood me. I mean, what would they like you to pay them, for them to be 100% transparent about what they're doing for tracking, what their advertisers are doing and who they are, and possibly stopping all that entirely. Ie, what is it worth to them.

> You're correct of course, but I don't really see how this isn't a vacuous observation. Yes clearly our perceptions are at odds, but that has nothing to do with the reality of whether or not they need to be doing that tracking. Obviously they think they need to, or they wouldn't do it. But I think I've laid out a pretty strong argument that they actually don't need to, which leads me to believe that they actually haven't considered it seriously enough to give it a shot.

It most definitely is. But so is the word need, in this context. How would we define what they need to do, and what they don't need to do?

My argument is simply such that, of course they don't need to (by my definition), but nothing will change that unless they see a different, more lucrative offer. Ie, "oh hey, here's 2 million readers who will only read the page in plain html and will pay an extra $20/m". It just seems like a needless argument, as I don't believe there's anything that can change their behavior without us changing ours. Without the market changing.

Rather, I think the solution lies not in them, but in you. In us. To use blockers and filters to such an extreme degree that it's made clear that UX wins here, and they need to provide the UX to retain the customers.

Thus far, we've not done enough to change their "need". If a day comes that they do need to stop tracking us, well, they'll either live or die. But the problem, and solution, lies in us. My 2c.

> Why is that doubtful? There's all kinds of examples of tiered subscriptions in the world. I think it would be doubtful because the NYT wouldn't want to explicitly admit all the tracking they are doing.

Many reasons, one of which you said. What would the price tag be for them to admit all they are tracking?

> No they don't. They really don't need to know any of that. They don't even get a pass on tracking because they're providing a free whatever - I pay for a subscription to the NYT. The business, or a meaningfully substantial core of it, is viable without tracking.

Clearly they disagree. Or maybe you should let them know that they don't need that.

To say it without sarcasm, what you feel you are entitled as a paying customer and what they feel they need/want to understand their customers are clearly at odds. Ultimately, what you think matters nothing in isolation and what they think matters nothing in isolation. What you two agree upon, is the only thing that matters. That is to say, if you think they shouldn't track you but you use their tracking product anyway, you've compromised and agreed to new terms.

I imagine you could come up with a subscription that would adequately compensate them for a truly no tracking experience. But I doubt you two would agree on a price to pay for said UX.

Is that really preventative care though? Why would I take pills for high blood pressure, if I don't have high blood pressure already? I thought preventative care was care that is, well, in prevention of the problem. Ie, checkups and recipes to exercise more.. or eat less carbs, or do more cardio. or w/e.

I know nothing on the subject, so please take this as a question.

Even more than that; I left Google (as a user, never employee) because I was scared of being banned. Seeing stories of users on Amazon / Google getting their account banned due to something related to a business concern, made me realize that if someone flagged a google app I had my whole life could come to a grinding halt. Phone, phone number, email, storage, internet access! All that because maybe I got reports on a phone app I wrote (hypothetical).

I'm doing nothing illegal or unethical, nothing wrong. Nevertheless, I ran from Google asap due to that reason alone. Google represented a massive single point of failure to my digital life.

I now use separate products for just about everything I own. While it's not as convenient as Google, I feel far more secure.

Go is my daily driver. With that said, I love Rust. I even tried to switch my team to Rust for a short while, and used it as my main personal language for ~8Mo or so. My decisions to stick with Go were mainly the following:

1. For work, my team just wasn't going to switch to Rust. From a Python shop, Go has enough pushback. Which tells you a lot about my shop lol. I'm still holding out for Rust on a future project that I think can't be Go, and has to be Rust.

2. For work and home, Go just feels easier and faster in mental overhead with the exception of one thing[1]. Which ultimately means if I need to blindly program my way through a vague feature description, and then find out it's way different than they said, it's easier to refactor and retroactively fix a bad design in Go than Rust.

3. For work and home, Rust had a terrible dev UX when cross compiling HTTPS. I was trying to cross compile my HTTPS Rust binary, an easy task in Go, and in Rust it was a massive headache. In Go it's an afterthought. This will improve in time I'm sure, but the easiest solution in Rust was to not do it, compile on the platform it's running on.

[1]: As said, I find Go to have less overhead than Rust; Except, for any type of optional value. Go's lack of enum types and Rust's Option<> is a huge blow for me. I absolutely love Option in Rust.

Appreciate the info! That's a nice way to look at it