You can easily compare to the figures for other games that are also on GamePass. Another Crab's Treasure, for example, had 4.7k Steam players on launch, of a similar nicheness stratum.
Which games of their output were Xbox exclusive? They were basically transitioning into a publishing house with no real hardware impact. In fact what did Phil in finally was trying to sabotage the hardware brand itself with the 'This is an Xbox' campaign. I said out loud when I saw the first ad, 'Phil will get shitcanned for this.'
It's not very complicated to import the QUIC library, or to import the HTTP library with HTTP/3 supported. For the library authors, QUIC isn't more complicated to implement than TCP. Doomsaying about the complexity of Google Sheets is completely unrelated to whether QUIC is good tech and superior to TCP, which it is; the only remaining complaint is that it's too new to have been part of the kernel yet, and if that makes technology somehow illegitimate then I guess we're just stuck with the mistakes of the 90s forever, why ever invent anything new at all.
I don't feel entitled to personal isolation from people who might want to strike up a conversation. If I'm not in the mood, I'll just say so.
I feel entitled to personal isolation from schizophrenics, who have a good chance of assaulting me if I look at them wrong. (And did you think screaming and playing loud music was disruptive just to quiet, and not to the aforementioned conversation too?)
You are the problem, not the person you're replying to. When you say 'you must exhibit infinite tolerance of antisocial disruption', the easy response is 'or I could always just leave'.
Yes this, yes that, yes the other, because proxies are in agreement with patterns are in agreement with the HTTP spec that methods exist and have semantic and functional requirements. Your 'should' seems to be discussing a hypothetical technology that is not HTTP, because HTTP has worked this way since 1997.
What are you talking about? The point of WASI is to stabilize WASM's access to OS APIs. It uses the component model to do this, which is bound to by languages that compile to WASM and by runtimes that run WASM. That is the only kind of interoperability that is required for this WASM system for WASM components to do WASM things.
We evaluated Extism and concluded that it did basically nothing that WASI and the component model didn't already do out of the box. Was your experience different?
WASI is the best format for code submitted by users, entirely untrusted, which is in principle of any complexity but expected to be pretty simple. It works on any platform, in any environment, with extreme and direct control over its access to every resource and its ability to execute at all. Wasmtime's "fuel" feature is not something you can do with containers, and if you can do it with VMs then I don't know about it, but VMs are behemoths for the task of executing a simple function that would in an alternate universe be CEL.
The present component model is "simple and stable". It is presently providing "interoperability between different ecosystems" and has been for years. It has basically nothing in common with CORBA. All the major problems with the Unix design they ran into that caused them to switch to a component model haven't vanished; the component model is still the best way of solving WASM's major complications that traditional C-based designs don't have. C-based designs, in general, are not better just because they came first; if you were designing systems programming from scratch, you'd want something like WIT (proof: Microsoft has done this twice now).
I don't think any of this relates to the post it's replying to. I appreciate the totally failed attempt to psychoanalyze my emotions, though. If you think I'm 'confused, surprised, and angry', you don't seem to be as good at the emotions thing as you keep acting like you are.
None of the languages you mentioned support this 'eager_fallback' feature, no. I am not stuck on any one application of the feature (you'll notice I referred both to the individual application and the general feature, and then you ignored it), but rather you are overindexing on generic returns, which are insufficient for what you're describing in a load-bearing way. Rust supports what C# supports, on the subject of generics (in ways germane to this feature), and what Rust lacks, C# also lacks. So your reference to C# supporting this is false. The feature you are proposing exists in zero languages on the planet. The thing you can get, top-generic returns, exist in Rust and the languages you mentioned, and don't accomplish your named goal at all because you can't use them as a method receiver without disambiguating them.
If someone spouts untruths, that is a failing of theirs. Talking about how there's emotions of theirs that back this promulgation of untruths, emotions which you could understand if you tried, is putting the cart before the horse. First express things that are not trivially false, then I will try to understand what you mean by it.
Why is the guy being rigorous worthy of criticism, but the guys being idiots aren't? Did you post any similar calm-down comments in either of the HN threads on the original attacks?
In none of the languages you mentioned do stdlib functions either return an iterator or a list depending on whether you feed it into an iterator operation; in none of the languages you mentioned can a fully-generic return as a method receiver be inferred by the name of the method. It has nothing to do with how well you explained it; it just doesn't exist. Every single thing you are complaining about exists in all of the languages you brought up, although Perl does a small portion of that in some cases depending on the variable sigil (ie still not guessed).
Your post is a restricted special case of "it would be great if any old sequence of characters compiled correctly and the compiler just read my mind". Wouldn't it just, but the rules of programming languages exist for more purposes than just annoying the user.
You may notice no language on the planet does this. That is because it is bad. Type guesstimation is a great way of ensuring random problems crop up in random places where they aren't expected and of making the typechecker much slower and more prone to unresolvability (see Swift's multi-minute compiles). All to save you from having to learn what an iterator is, in case you come from a language where lists are more common than iterators; the experience of being scared by a type, and then discovering that the type is not scary in chapter 13.2, is not actually worth making the simple type system instead staggeringly complicated.
In my experience working with newbies, the alterations Brown makes to the chapters on borrowing are strictly worse. It is entirely focused on ramming the difference between the stack and the heap down your throat, which has nothing to do with ownership and borrowing, and newbies will frequently say that they are extremely confused by the chapter, then sigh in relief upon reading the original version. Just use the official guide, nobody has improved upon it yet. https://doc.rust-lang.org/book
And then you look it up once, and now you know what it means forever. By contrast, the former expression is much wider with more going on, and furthermore you can't skim past it being sure nothing funny is going on because it may or may not be a range compatible with the latter form.
By 2021, we'll have completely abandoned light switches. We'll just use an app on our phones to turn off the light in the bedroom, or perhaps request out loud for Alexa to do so. The future is the Internet of Things.
I think this article is too soft a criticism by half. The iPhone defining the mobile era was not an artefact of the Apple logo being on it. Every bit of Apple's relentless productization went into what features the phone actually had and how they were integrated. This guy, in 2006, would have been telling Apple 'just release a feature phone like BlackBerry does, so you can define the era of feature phones like you did MP3 players'.