I would assume it's mostly marketing. There's no entity behind IRC to push its adoption and herd the cats to a singular goal.
The lack of features that Slack/Discord specifically added to differentiate themselves from IRC are also important, but it was a lot simpler to add them to their brand new designs, than to work through having to specify them onto the IRC protocol and then get servers and clients to adopt it. You can look at the IRCv3 page linked higher in the thread to see some of the efforts, but this is 10 years later and we're still not there. :D
I think that the biggest IRC channels are on twitch. Large streamers have tens of thousands of people in their channels, and probably the servers must have millions in aggregate.
I didn't know twitch uses IRC, though I wouldn't categorize in the same box as traditional channels and networks either. I mean, the protocol might be the same, but it clearly is used in an entirely different context.
I mean, you can connect to twitch using a standard IRC client. And it works equally well, better in some respects, as the browser chat has become a sluggish mess. There are stand-alone twitch chat clients now which support all its extra bling, but AFAIK they are just glorified IRC clients.
Tell me you're young without telling me you're young. Friendships are more than just meat space meetings. Children, moving countries, crazy work schedules are all reasons that can prevent you being in the physical presence o your friends. Does not seeing them for years at a time make them less friends? No, not to me.
There's a degree to how much you continue to engage with people once they've made that decision to leave though. Once someone's on the other side of the world, you're not keeping the friendship up by viewing their Instagram/Facebook posts, it's a totally one sided consumption unless you continue to speak to one another at least semi-regularly.
> PC gaming is a very small market... and PC game pass
I think you're very much wrong. The game pass market is said to have ~30 million users. Having them be able to play on PC is probably quite important as not everyone can afford an extra Xbox if they already have a computer.
Your argument is not very convincing unless you can show numbers of people who have an Game Pass Ultimate subscription and use it for PC gaming.
> not everyone can afford an extra Xbox if they already have a computer
Gaming PCs are much, much more expensive than consoles at same performance. Most people have consoles and no gaming PC. In markets where that's not the case (e.g. China), game pass and Xbox in general happen to be also less relevant -- if they get a console, they'll get a PS5.
Every teen wants a gaming PC because all their favorite streamers and YouTubers play on PC. It's not 2010 anymore. Walk into any big box store and there's pre built gaming PCs of various price bracket. Even Costco has like 5 different models right near the entrance.
You've literally provided the evidence that Microsoft cares about PC gaming in your original post.
I think you're talking about generic Linux distributions without a corporate backed concerted and invested effort into it succeeding.
A Linux based Steam console OS is a very different beast, and it's less about "the year of the Linux desktop", and more about "the year/decade of the Steam based console". And my assumption is that the underlying OS is probably meaningless despite the amount of effort Valve devs have put into Steam OS, Proton, and all the other intermediary pieces. If the Linux desktop gets better in the process it's probably a happy coincidence, but I doubt it very much that is an actual KPI for anyone at Valve.
If one gets into the books that invent their own dialect, the most dense I found was "Riddley Walker" by Hoban Russel. As a non native English reader it was very difficult to make progress, but once the understanding settles in, it's a pretty nice story. Also of note is Anathem, even though Stephenson's jargon is more accessible, I think, to Latin languages speakers.
My suggestion would be to try Purelymail. They don't offer much in the way of a web interface to email, but if you bring your own client, it's a very good provider.
I'm paying something like $10 per year for multiple domains with multiple email addresses (though with little traffic). I've been using them for about 5 years and I had absolutely no issues.
Why do you need to put faith in them? Switching email providers is just a DNS change away, and email messages can be stored locally - actually it's encouraged to do so.
You do have a point. But I still do not feel comfortable. Besides I can't envisage changing providers whenever I face trouble and it gets unresolved in a timely manner which is what I assume in the current setup. Pinboard is another example. Anyway, it kind of doesn't work for me.
Personally I use the simple pricing scheme and looking at billing page, I pay around ~$0.35-0.4 monthly for 5 domains, with 4 explicitly set email addresses and catch-all for all domains to a common mailbox. Also I must state again, there is quite little traffic on all.
Do you maybe have a constructive advice for people that need to return errors that demand different behaviour from the calling code?
I gave an example higher in the thread: if searching for the entity that owns the creds.json files fails, we want to return a 404 HTTP error, but if creds.json itself is missing, we want a 401 HTTP error. What would be the idiomatic way of achieving this in your opinion?
With some of these examples, I'd change the API of the lower-level methods. Instead of a (Credentials, err) and the err is a NotFound sometimes, I'd rather make it a (*Credentials, bool, err) so you can have a (creds, found, err), and err would be used for actual errors like "File not found"/"File unreadable"/...
But other than that, there is nothing wrong with having sentinel errors or custom error types on your subsystem / module boundaries, like ErrCredentialsNotFetched, ErrUserNotFound, ErrFileInvalid and such. That's just good abstraction.
The main worry is: How many errors do you actually need, and how many functions need to mess about with the errors going around? More error types mean harder maintenance in the future because code will rely on those. Many plumbing or workflow functions probably should just hand the errors upwards because they can't do much about it anyways.
A lot of the details in the errors of the article very much feel like business logic and API design is getting conflated with the error framework.
Is "Cannot edit a whatsapp message template more than 24 hours" or "the users account is locked" really an error like "cannot open creds.json: permission denied" or "cannot query database: connection refused"? You can create working code like that, but I can also use exceptions for control flow. I'd expect these things to come from some OpenAPI spec and some controller-code make this decision in an if statement.
Use errors.Is and compare to the returned err to mypkg.ErrOwnerNotExists and mypkg.ErrMissingConfig and the handler decides which status code is appropriate
Cool, but error.Is what? In my case would both come as a os.NotExist errors because both are files on the disk.
I think that the original dismissal I replied to, might not have taken into account some of the complexities that OP most likely has given thought to and made decisions accordingly. Among those there's the need to extract or append the additional information OP seems to require (request id, tracking information, etc). Maybe it can be done all at the top level, but maybe not, maybe some come from deeper in the stack and need to be passed upwards.
no no no; do not return os.NotExists in both cases. The function needs to handle os.NotExists and then return mypkg.ErrOwnerNotExists or mypkg.ErrMissingConfig (or whatever names) depending on the state in the function.
The os.NotExists error is an implementation detail that is not important to callers. Callers shouldn't care about files on disk as that is leaking abstraction info. What if the function decides to move those configs to s3? Then callers have to update to handle s3 errors? No way. Return errors specific to your function that abstract the underlying implementation.
Second edit: same code, but leveraging my other comment's kverr package to propagate context like kv pairs up the stack for logging:
https://go.dev/play/p/pSk3s0Roysm
Exactly, and that's what OP argues for, albeit in a very complex manner.
Distilling their implementation to the basics, that's what we get: typed errors that wrap the Go standard library's ones with custom logic. Frankly I doubt that the API your library exposes (kv maps) vs OPs typed structs, is better. Maybe their main issue is relying on stuffing all error types in the same module, instead of having each independent app coming up with their own, but probably that's because they need the behaviour for handling those errors at the top of the calling stack is uniform and has only one implementation.
A quick back of the napkin list for what an error needs to contain to be useful in a post execution debugging context would be:
* calling stack
* traceability info like (request id, trace id, etc)
* data for the handling code to make meaningful distinction about how to handle the error
I think your library could be used for the last two, but I don't know how you store calling stack in kv pairs without some serious handwaving. Also kv is unreliable because it's not compile time checked to match at both ends.
I'm not saying use kverr for explicit error handling (like, you could, but that is non ideal), use kverr as a context bag of data you want to capture in a log. If you programmatically are routing with untyped string data, I agree, unreliable
The lack of features that Slack/Discord specifically added to differentiate themselves from IRC are also important, but it was a lot simpler to add them to their brand new designs, than to work through having to specify them onto the IRC protocol and then get servers and clients to adopt it. You can look at the IRCv3 page linked higher in the thread to see some of the efforts, but this is 10 years later and we're still not there. :D
reply