Yep, or if you're just doing a numpad.
562 karma · joined March 31, 2013
No, it never does. Those people somehow delude themselves into thinking it might, but...it might just work for us.
For The Witness, I would recommend tagging it as appropriately not accessible. There is a section that can't be completed at all without hearing, and large chunks of the game that I can't imagine are possible with color blindness. I don't have either of these issues, but running into those things really rubbed me the wrong way. It is a game that seems to value the creators vision above all else and isn't willing to make any sacrifices for the audience.
Edit: I realize I misread and thought you were saying you were going to add The Witness to the non-gamer list, which was why I was saying that a disclaimer would be extra useful. Left it anyway.
-K5ETC
Happy proton user that doesn't need this feature, but gets why it would be frustrating for others who want a clean way to move off if they decide to.
>Mozilla and the Rust Core Team are happy to announce plans to create a Rust foundation. Our goal is to have the first iteration of the foundation up and running by the end of the year.
I read this as "Mozilla is currently still largely in control. This is the moment where they will cede to the new, more independent, foundation." But the fact that it follows "Mozilla and the Rust Core Team" with "our" may taint the rest of the use of "our" throughout the post for others.
var (f, l) = person;
var (x, y) = point;
For instance you linked the spring application events integration with redis, while that is definitely an option it's not one you'd immediately reach for. Instead you'd more likely set up and use application events and/or domain events (if using spring data) handled locally with thread pool. The benefit here is that of course way less set up and complexity, but you can also handle these events sync or async.
Anyhow, your characterization there I don't think is quite right. For one Java does not typically use a background job set up, because it is a first-class multithreaded runtime so it seems more likely prepared to use a threadpool for some concurrent processing before it say tosses things out to a task queue. Similarly as most java web servers are on a thread pool model for concurrency as opposed to async IO, you'll also have true in request concurrency for things like making a few calls to the DB and then collecting them. This thread pool is not well abstracted typically, and the mutable object model leads you to writing classically tricky multithreaded code with data races and the like.
For something like node where you are not really likely to be using threads, you are pretty hard tied to async IO as your method of concurrency. So you have a really easy job if all you're doing is async calls to say a DB with no need for data processing. Here once you need real computation you will have essentially no option other than using a task queue.
Then when it comes to python you have essentially the worst of all worlds. it's not easy to do concurrent IO or computation without some form of background processing.
I believe that when it comes to the elixir runtime the idea is that they have removed async IO from the mix and instead put up a concurrency API that is as simple to manage as async IO in something like node. Under the covers is all delegating out simple blocking code to a thread/process pool, but the immutable data model and API makes it so that data is not shared across the pool, trying to keep the classic concurrent mistakes hard to make.
Nothing that can be done in elixir seem to be impossible or even astoundingly hard in some other technology, but the unified API for all forms of concurrency seem like a nice way to make it a runtime that can handle many different types of workloads in a simple and cohesive way. That simple way also seeming to not need you to bring in things like a redis task queue where you generally would need to use it or some other external solution.
As for more beneficial, I'm sure learning a real practical machine language is more beneficial. However you can definitely draw some of the same lessons out of these games and depending on you, might have a lot more fun and chances of actually going through with playing these games.
I believe presenting slightly more open commands for internal use is the right idea, but sliding all the way to an arbitrary entity edit API is a quick way to break state expectations.
Yes this could also be solved by having perfectly crafted constraints in the business logic and/or DB, but what's more manageable? Managing a few extra specific APIs, or having every expectation perfectly defensively coded?