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.

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.

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".

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.

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.

Many reasons, one of which you said. What would the price tag be for them to admit all they are 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.

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

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.

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.

Currently I'm using Zerolog, which has a nice compromise of UX, performance and adoption. The less cost the better if my application logs with a level that is not enabled.

Definitely. Furthermore, I typically don't even care about things going fast. I want things to "not be slow". Which, typically I guess the distinction is that I don't mind expected slow things being slow. Ie, if I have to run integration tests I expect it to take 30s. If I got a (somehow) faster SSD and CPU could it take 20s? Maybe, and sure that would be great.. but .. meh. It just doesn't matter to me.

However the things that should be instant, that I don't like to be slow need to remain so under all conditions. In my experience, RAM is the biggest culprit for causing simple things to be slow. If I open one to many browser tabs, suddenly I have no RAM and my UX goes down significantly.

So RAM ranks far, far higher on my list than CPU. CPU rarely has a big affect on my these days, and unless I switch to a workload where I'm heavily concerned with shaving time off of hour+ compiles (video editing/etc), then I just don't care. But RAM, oh boy do I love RAM.

On the flip side, a drug that let you retroactively forget would be heavily used I bet. Traumatic experiences are often wished to be forgotten. Though, I wonder what a human would be like if they didn't have negative experiences. One who was able to remove a big portion of mind shaping experiences. Further yet, I wonder if your mind ever truly forgets. If a dog bites you as a kid, and then you take the forget pill, are you still afraid of dogs?

This, funny enough, reminds me of Go. We've been having debates about how to improve syntax of `if err != nil { return err }`, and many of us (myself included) disliked helpers to immediately return or hide an error value.

The reason is that `if err != nil { return err }` is actually somewhat non-idiomatic. It returns the error value with no additional context of where the error occurred, what is wrong, etc. So something like `returnif` in Go, I think is bad. For reference, this is a more idiomatic example: `if err != nil { return fmt.Errorf("foo bar: %v",err) }` where `foo bar` adds context about the thing returning the error.

So perhaps my Go logic doesn't apply here in JS land, but it seems like a bad keyword, if it's similar to Go.

In the future it may work, because a built in GC is on the roadmap for WASM. Unfortunately I'm not sure that it will work great for most scenarios. For example, Go(lang) ships with its own GC which is very tailored to its use case. Defaulting to a WASM GC could work, in theory, but would it impose difficulties such as unexpected performance characteristics with longer GC pauses or whatever?

There's a lot of edge cases that will have to be covered for this stuff to work instead. Perhaps shared WASM binaries would be the best solution, allowing runtimes to be offloaded and cached regardless of user land code running.