I imagine it would be a fairly trivial application of computer vision to make an aimbot for first person shooters that works most of the time.
2,428 karma · joined May 4, 2016
I imagine it would be a fairly trivial application of computer vision to make an aimbot for first person shooters that works most of the time.
They're both statically typed compiled system programming languages; both trying to provide solutions for safe memory and concurrency.
JavaScript has changed a lot as a language over time -- ECMAScript 2019 makes it a lot easier to write good code than the original JavaScript. It's now better understood how to write JavaScript code, and how not to.
On the other hand, Golang is a much simpler language. It's relatively easy to learn and understand.
It's a fairly simple language, which makes it relatively easy to grasp and understand the majority of Go code. This is particularly useful for group development (i.e. in companies), where you want everyone to understand each others' work.
Anecdotally, although I prefer to write Rust, and consider it a better language in many ways, it took me a lot longer to learn the language, and longer still to write idiomatic Rust code. I was up to speed with Golang relatively quickly.
Rob Pike was famous before its creation (within the relevant community). The language was designed within Google, and gained much hype from that. The effort to foster a community paid dividends.
Writing Go code for a living, I find it a very mediocre language. It's largely redeemed by its library ecosystem, which reflects not on the language, but the enormous size of its community and commercial backing.
If anything is noteworthy about its design, it's that it's simple (crucially, to those already familiar with C-like languages), and easy to bring people on board. What is lost for want of features and abstractions, is gained in human resource.
I'm not sure I'd agree though; Swift shares this position with its predecessor Objective-C. Swift's success versus Objective-C can be attributed to its relative merits as a programming language.
This depends on your interpretation. It could be argued that China's state capitalism -- where the state is the dominant capitalist, and owns most of the companies, property, and natural resources, is a form of communism, perhaps the most effective realisation of communism seen so far.
True private ownership is very limited, as property rights are subordinate to the will of the state. Land can not be owned as freehold, and is instead leased from the state.
Capturing a non-violent criminal would not typically justify a high risk of causing a deadly road traffic accident. In the UK for instance, the National Decision Model must be used to evaluate whether to pursue a criminal; authorisation must be requested to conduct a pursuit.
I expect the police would be liable if a court found them to have caused damage which was completely unnecessary, although they have a lot of latitude in interpreting this. It's fairly easy to argue that doing whatever is safest for them (doesn't put them in the line of fire) is justified, and they shouldn't take any unnecessary risk to protect property.
Given that (rightly or wrongly) typically the police will not be liable for these situations, and the liable criminal will be unable to compensate, the burden should probably fall to insurers.
I wonder if this is because the hard IP is specific to the fabs' trade secret tooling, and so subject to their NDAs, making it impossible to distribute publicly.
SiFive offer IP but also produce SoCs (presumably with TSMC, SMIC, and GlobalFoundries, who are listed as partners).
The sanctioned use of weapons is against belligerents. The intentional killing or torture of civilians or prisoners is a human rights violation, or a war crime during warfare.
My understanding is that Saudi Arabia has poor diplomatic relations with Israel.
> The findings suggest that very young children are missing out on key aspects of their brain development when they spend so much time staring at a screen instead of interacting with the outside world.
Or alternatively, they suggest that victims of bullying, less socially successful, and less physically fit children are more inclined to spend time using a screen.
So often studies like this find a correlation, then jump to the causation they had set out to find, ignoring all other plausible relationships suggested by the data.
Except we're talking about variable sized arrays, where the wanted size is not known until runtime (e.g. from user input). We can't check this at compile time.
This also isn't the same problem as an out of memory error; we need to check that nn didn't overflow the size of size_t, as well as that the memory allocation is successful. Something like:
int n = /* run-time value */
size_t sz = (size_t)n;
// Check n fits in size_t.
if ((int)sz != n) <error>
sz *= sz * sizeof(float);
// Check against overflow.
if (((sz / (size_t)n) / sizeof(float)) != (size_t)n) <error>
float *matrix = malloc(sz);
// Check allocation succeeded.
if (matrix == NULL) <error>(Used · for multiplication, because HN turns stars into emphasis.)
The Duff's device is still useful for creating co-routines though; a handy way of yielding, then returning to the yield point.
That said, in ideal conditions, even with rotation, the bullet will hit you eventually, but not for a long time on average, given the scale of the moon. In reality it's orbit would probably destabilise due to collisions with dust and perturbations from other gravitational bodies (the Earth, Sun, etc. create an n-body situation which slowly changes the orbit over time).
> Does there always exist a velocity `v(theta)` that will make the bullet hit you in the back after one orbit?
The velocity must be great enough to stay above the surface, and not high enough to escape. Additionally, you must shoot horizontally, like I mentioned before, and not rotate out of the orbit (e.g. by being at the poles, or at the rotational equator, shooting along the equator).
Eliminating ports seems to be some manufacturers' solution to this. There's no wear if it doesn't exist.
> There is also 'glue & waterproofing wear' as the glue & rubber goes through multiple heat / cooling cycles and unsets, then water damage occurs.
I wonder if in the future, the glass will just be hermetically welded to the case (glass-to-metal seal). No moving parts; no external adhesives; no possibly of getting into the device without cutting through it.
In most cases no. Although the orbit of the bullet is cyclical (below escape velocity), unless you shoot perfectly level with the surface, its orbit will intersect the moon. Obviously if you shoot slightly down, it'll hit the ground. If you shoot slightly up, it'll hit the ground behind you on its return.
> Is this the velocity required for a bullet to leave orbit no matter what angle you shoot it?
Yes. Although if it hits the moon first, it'll slow down and not escape (unless you were to shoot through the moon).
Ironically, I do enable them on my tablet, because I don't always have a keyboard attached to it. Tablets generally have enough space for full menus / toolbars, and lacking a keyboard they're arguably the form factor most in need of them.
Maybe the legislative solution we should be pursuing is longer mandatory warranties.
That said, in many cases a device fails due to a low value discrete component -- a resistor; a capacitor. This repair legislation would help here.
What individuals can do to repair a device isn't particularly relevant to this discussion. The legislation seeks to force manufacturers to make repair manuals available to independent repair shops. It's fairly common for such establishments to have the tools and expertise to replace soldered components.
Transporting batteries might make sense for some extremely remote locations with no grid access, but people don't commonly drive far away from the grid. As these batteries are very heavy, I would expect the handling involved to make this far more expensive than just charging on-site.
It was developed and demonstrated. https://www.youtube.com/watch?v=H5V0vL3nnHY My understanding is that it was deemed more unnecessary than unfeasible. That it would change the battery ownership model would also create administrative complications too.
Supercharging improved to 250kW, bringing down charging times. That people need to recharge their Tesla at intervals when they should probably take a break from driving anyway, on the occasions when they take long road trips, makes it hard to justify a battery swapping program.