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)
1,642 karma · joined November 17, 2016
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.
Coffee: 3-4 cups a day. Typically 2-3 in the morning, and 1 in the afternoon after work. This has gone up and down over the years, in the past I've drank a lot, upwards of a full pot. Then I developed an eye twitch. Now I'm trying to control that intake. Lowest I think I've been is 2 in the morning, 1 in afternoon.
In simple terms, at least.
Ie, in a purely technical sense corporations shouldn't want any laws/regulations. But that's not really a relevant fact to anything, is it?
From oil companies, to fishing companies, to waste disposal to whatever, most companies from a purely technical viewpoint would be more than happy to get rid of regulations that control what and how they can do business. Yet, we have those regulations in place for a reason.
In this case we simply ask that ISPs deliver the bits we paid for. I don't want Comcast treating my bits differently anymore than I want my mail carrier to hold my packages ransom because they seem important and I'd probably pay more for them.
My mail carrier doesn't read my mail. Comcast shouldn't either.
What I don't get is, both Netflix and I pay for bandwidth. As far as consumer bandwidth (mine) is concerned, why should Comcast care if it's 1TB/month coming from a thousand sites or just one. I paid for the data, I paid for the bandwidth, give me my bandwidth.
Likewise, Netflix paid for their own too, with whoever is their ISP.
Conceptually the bandwidth has to be paid for, and I could see your argument if I only paid a portion of what it costs to transfer the data.. but that is a broken model if that's the way it is. I want to pay for data, and I shouldn't have to get Movies.com to pay Comcast to serve me movies. I paid Comcast for data, it doesn't matter who it's from. My data is my data.
Is this wrong somehow to you? Honestly it's a strange argument from you, I have a hard time understanding. Like, if you run a website and I visit your website, do you think you should have to pay my ISP for data I'm downloading from your site? That's a bizarre system in my mind.
I know you're not suggesting everything needs to be perfect. We just have different lines we draw where our UX outweighs things like RAM or disk space. For me, if it gives a great UX, 75MB is a tiny fraction of my RAM, I'd gladly pay it.
Besides, I'm only going to have one copy of this thing running. If it was 75MBx25 or something then I'd be concerned, but 75x1? meh.
Two things I dislike though, 1) as far as I can tell the dates/times can't trigger notifications. 2) the paid plan is expensive.. they give so much away for free, but then charge a lot for seemingly little. A $3/m tier is a good price point imo for a todo app. Right now it costs basically the same as Netflix..
Out of curiosity, any idea what formats you'd choose to embed in a Github readme? Videos or otherwise, I'm not sure which play well when embedded, and are GitHub allowed, etc.
I loathe YAML for readability. When I'm 2 pages down on a yaml tree I have no clue how many indents exist before what I'm working on. Likewise, when I scroll up, I quickly lose track of what the actual parent to the data I was working on is. I've found it to be an absolute mess.
JSON doesn't even fit for me, because it's not human intended (imo). Being able to document (comments) configuration is a requirement for me on any config language.