Considering that pretty much all multiplayer games in existence perform some sort of local prediction / state interpolation to hide the lag on the local machine, cloud only multiplayer will be considerably worse. After all you can no longer hide the lag locally, since you're not computing anything on the local machine, so the minimum precieved lag will go from 0 (for movement of your own player character) to the RT between the datacenter and your PC :/
I actually wrote a Asteroids "Clone" that uses Vector Graphics last year :) [0]
But I agree, tooling is complicated. I'm currently adding the finishing touches to the rewrite of my own Assembler / Compiler pipeline [1] and started work on a more "traditional" Metroid-like shooter, the sprite and map editor are both custom programs written in rust using imgui bindings and take care of the grunt work for generating all the data structures used in the game currently the dev efforts are 50/50 tooling/game though :D
That however goes both ways, making it also far easier to install a dictatorship etc. because you don't have to replace tens of thousands of police officers with regime loyal ones.
We're walking on razors edge here, it only takes one "election gone wrong" and we might find ourselves in a nightmare with no escape.
Plus the fact that you can't directly write to VRAM at all times and have to wait for the corresponding access windows.
But it's also a big contributor to the general art style and gameplay limitations for which the games of that generation are known for.
However with a few tricks drawing vector like graphics is possible[1] (to some degree), even though it requires a huge amount of lookup tables to be anywhere near peforment :D
Factories in Orbit, pretty much. There might not be many products today which will benefit from this ability, but a free fall environment brings many benefits to things such as crystallization of materials.
For example, the last resupply mission of Space X to the ISS included an experiment to product optical fibers onboard the space station, the goal is that these fibers will have a much lower number of defects in their crystalline structure then their earth produced counterparts, this means less refraction, which results in less signal loss over a longer distance which reduces the number of repeaters which reduces increases the overall signal speed.
Now, of course if you wanted to deploy these things on a world wide scale you'll need to set up a bigger shop then the ISS - which most likely will go out of service within the next decade anyway...
And while the moon does not provide a free fall environment such as LEO, the gravitational influence is still much lower than on earth itself and scaling up on a surface will most likely prove easier in the long term than doing so in orbit around the earth.
They are simply ignoring the real world economic impacts though, which is stubborn to say the least.
The world is no utopia, and as long as money / economic gain is the utmost priority for most of humanity and its corporations, allowing widespread use of patented G.M.O.s will only cause more damage in the long run.
Imagine a whole countries population being dependent upon a companies patented seeds. Now add some secret courts implemented via trade agreements so the country is effectively unable to just "use" these seeds without paying up incredible amounts of money and suddenly you got yourself a situation where the country might end up under effective control by the company.
Yes there's probably still a way out of this dilemma, but with the right/wrong people coming to power through the course of action, you might quickly end up with nationalist government for which the most easy solution is out is a war.
Currently a lot of fincancial products can be created and managed in London, since once approved there, they are automatically approved in all other EU member states, too.
This of course will have to change once the UK has left the EU, making the people involved in these processes one of the first to be moved to Franfkurt etc.
It is actually the other way around. Internal producers simply cannot compete with external ones who can produce in multiple countries, in giant quantities at very low overhead cost and then sell reject goods for a very low price.
Africa has a big problem with this. Due to trade agreements, many European meat producers sell their "leftovers" into the African market at extremely low costs, which has lead to the demise of domestic producers of live stock. Which then resulted in a loss of jobs.
Yes, some people might be able to purchase things at a lower cost now, but some other people will loose their jobs and won't be able to purchase anything at all, which also negatively affects the domestic market.
For the outside producer is not a problem, they simply can move on. But kick starting a domestic market and bringing wages back up again will be huge issue for any government in the long run.
Compared to the current situation of writing a few lines and then having to wait for a vendor specific day one graphics driver update to have your game actually running at halfway decent speed, it is simple.
The current APIs are a giant collection for graphics vendor specific driver "fixes" which had been implemented initially to cheat in benchmarks, and then later had to be implement to fix issues which arose from those initial cheats. It is a giant, ugly mess.
Also 95% of game developers will never ever touch a single line of vulkan because the engine developers of Unreal/Frostbite/CryEngine etc. will handle all of the "dirty work" for their abstractions to run on top of vulkan. All without the need of trying wo workaround vendor specific bug fixes etc.
One could assume that they are either simply lazy or incapable of designing such a system on their own. By taking a look at their "index" which consists of one giant directory in a single GitHub Repo, one could indeed argue that it's a mixture of both.
There are so many (big) companies out there using cocoapads for their app development, getting a few to sponsor the hosting bills should be more than doable. A lack of funding is really no excuse.
This would definitely be very interesting in regards to language study. Repeating the experiment with people which are actively in the progress of learning a new language every few weeks could give some remarkable insight in how the new words are being mapped onto the brain.
Point here is, all of this doesn't matter. The market doesn't care about "ethics" or whatever. The market only knows one thing: Demand.
And it will do whatever it takes to satisfy this demand. If this happens to be "subscribing to your awesome streaming service", well then good for you! If not, too bad, the market DOES NOT CARE about you.
So you can now either spend your money on lobbying to get these people into jail or try to expand your market and get the people's money into your pockets. The latter being obviously the better choice for both you and your future customers.
This is mostly about linters, makeprg's and things like Ctrl+P / Command+T, git-gutter etc.
I recently switched to NeoVim and it really _does_ make a world of difference, saving is a whole lot faster when git-diff can be performed asynchronously and the ability to scan directories in the background makes fuzzy searching of files a lot faster.
For smaller projects I definitely agree with having both unit and integration tests, especially for libraries. One thing to look out for is the fact that you can always "cheat" in unit tests, e.g. you can be "lazy" and set up some internal state directly in the test to skip huge amounts of initialization, this of course becomes a problem when there's no actual integration test for making sure that the exact state can also be triggered from the outside when using the API. In my experience, ensuring that these cases are always covered can become pretty complicated once the project grows.
In our special case we have about 100 different endpoints all versioned and all dependent on multiple endpoints from the (rather badly documented) APIs of our customer. Most of the work our API does is spent combining / enriching the customers data and performing integration across the subresources. Setting up individual mocks for every single on of these complex requests flows manually is pretty much impossible at this scale.
So doing black box testing and enforcing a 100% test coverage (best for avoiding dead code) helps keeping us sane. In the end we don't care so much about how the implementation behind our HTTP response looks as long as we return the correct data in the end. The code itself still has to look good though :)
I in part agree with the pinpointing, though in my experience this really boils down to an issue of scope and how much of the data you want to test in each of your tests. E.g. an API returning user data, do you have one test for the whole set of data or one test per field.
For our use case we have some pretty "fancy" deep-equals logic for nested structures and allow to specific fields as "to be ignored" in our test expectations.
When it comes to speed, the most important part is to cut out everything you don't need, for us this means that our testing framework completely throws away the internals of Node.js HTTP layer. We never create a single TCP socket in our tests, which gives an incredible speed up. As a bonus this also allows to test timeouts and low level HTTP errors in < 1ms, since we can just return the timeout directly from the low level APIs and Node.js will invoke the timeout event on the http client handle.
And yes, that really reads 10 seconds and yes I always get a bit bored when I have to run the tests for one of our Django backends, feels like an eternity... :)
One good way to the limit breakage in such cases is to solely perform black box tests on the API level. In case of our Node.js based Backends we don't ever write a single classical unit test, instead we have a custom Framework built on top of Mocha which performs tests on the HTTP layer against all of our endpoints.
This works remarkable well in practice and allows for large scale refactorings under the hood with little to no impact on the tests. We can also mock databases, memcached, redis and graylog on their respective http/tcp/udp level. This in turn means no custom build mocks which could break when refactoring. The tests itself also contain no logic, they are pretty much just chained method calls with data that should go in and an expected response that should come out, along with a specification of all external resource our API fetches during the request and their responses etc. Any unexpected outgoing HTTP request from our server will actually result in a test failure.
As for scaling this approach, from our experience it works quite well, especially when you have lots of complicated interactions with customer APIs during your requests since the flows are super quick to set up.
Yes, they use AdBlock, but there's still a difference here, right now they're seeing the tweets of their peers in-order, with ads intermixed - which makes the ads trivial to filter out (bad for twitter, good for my friends).
In the future they might see whatever Twitter thinks is important to them, which might still be ads, but in the form of other peoples / companies tweets which just "happen" to end up in their "timelines".
Now, of course they can start blocking just about every company/user they don't care / like on twitter, but the effort might not be worth the gains at some point. And who knows, maybe you won't event be able to block some things from their algorithmic timeline, because that might defeat their monetization goals.
And yes, I realize that I might be reading a lot into Twitter's actions at the moment, but given how they treated their platform in the past year(s), all I'm seeing is that they want monetize it at all costs.
Most of my friends actually use it as a async, direct and realtime communications channel, pretty much like Whatsapp, just with more "social integration" (read: the whole internet).
They don't use Facebook because its algorithmic "timeline" isn't realtime in any sense of the word and they consider themselves more than capable enough to decide on their own what's worth their time or not, they don't want to be fed things / advertisments somebody else wants them to see.
They'll probably all switch to the next best thing available once Twitter's rumoured algorithmic timeline is to be introduced.
Personally, I left the whole Twittersphere way back when the alienated their third party devs, for me that was more than enough indication of the way they were heading. Nowadays they have nobody left who could actually come up with the Next Big Thing (tm) for Twitter, because all of their engineers are mostlikely busy trying to figure out how to commercialize the platform in the shortest amount of time in order to satisfy their shareholders.
The real problem here is the fact that there is missing oversight on these court orders, since it might be the case that the judge handing out the order does not have sufficient knowledge of the matter at hand and so there is a huge potential for misuse by the police or intelligence agencies.
In the end it boils down to the simply dilemma of choosing between either catching all "criminals" or protecting the rights of the people.
The latter way of course makes life a bit harder, since you'll never be able to prevent all crimes and people will potentially die, but people die all the time, since dying is a a basic risk of life.
The former way is essentially a rabbit hole, because it allows you to rewrite the definition of a "criminal" to just about anything you'd like and once you get a court order the "criminal" being is pretty much done with their life. This of course was and is still used in dictatorships of all kinds of sizes and employed by numerous secret police agencies around the world. Once there is a way to criminalize any action and then instantly "get rid" of that person, people who are going to use these powers WILL pop up and take over power.
Now of course in the short term no third party candidate is going to show up on the US politcal floor and take win a majority in the elections over night and then install a dictator system based on all the pre-existing powers by simply outlawing all other parties and anyone who objects to the new rulers claims. But 10 or 20 years from now things might be different and if we don't fight over abuse of the law and protect the general public we might end up in a pretty bad situation someday.
Also cool to see myself featured there, so in case you need another homebrew game with access to the source try https://gitlab.com/BonsaiDen/vectroid.gb