I don't see any contradictions. There are day jobs, and there are 24/7 jobs. Someone working 9 to 5, 5 days a week isn't supposed to answer the phone after the work hours, that constitutes employer abuse. If the employer want to have someone always available, then they should hire people for 24/7 and pay accordingly.
Different countries have different methods of determining if COVID was the cause of death, but so far if I remember correctly only Belgium has excess mortality equivalent to attributed COVID deaths, thanks to their cause qualification method (if COVID is only suspected but wasn't diagnosed, it is attributed to COVID).
In general, "synthetic" drugs are more of a menace due to the ease of transportation and production. They don't have to be produced in specific geographic regions and can be very powerful, which adds up to dangerous combination.
Protocol Buffers is indeed relatively similar to FlatBuffers, with the primary difference being that FlatBuffers does not need a parsing/ unpacking step to a secondary representation before you can access data, often coupled with per-object memory allocation. The code is an order of magnitude bigger, too. Protocol Buffers has no optional text import/export.
Don't know, but in general arbitrarily set limits are bad. Note, the bug is not in the long name. The bug is in the inability of system services to handle a long device name. That I imagine is hard to fix, but this is exactly what needs fixing. Limiting the name length is akin to band aid.
I find it strange that the author treats spending time with a language as a personal sacrifice.
If that's the case, maybe quit programming altogether? No matter what you work on, language or a piece of software, if you think you are sacrificing part of yourself, just stop. It's not worth it.
Many commenters have rightly pointed out limited availability of eSIM offers comparing to physical cards. However, it should be noted that Apple has immense weight in carrier world. They may 'ask' carriers to provide SIM /eSIM parity for the next iPhone model. If they do, the rest will follow. Technically, there are no barriers to migrate SIM tariffs to eSIM.
Are you claiming that because modern CPUs have higher instructions per clock count means you can insert useless instructions without performance impact? That's ridiculous.
The comparison is against Java because it has certain feature parity with C#. And it is right, C# code can be brought closer to C level of performance with less effort than in Java.
I don't think it is bitterness. What really interesting is the idea he put forth: maybe you could find Bethlehem star out there, in space. I think that's brilliant.
If I'm not mistaken the hallmark of benchmark game is to use same looking source code and see how fast it runs written in different languages. Basically, it presumes that all languages follow the same programming paradigms.
To the left, right :)
But if you are following unbiased analyses, say from foreign financial publications, they do agree on economic downside of Brexit.
I've been watching Brexit as an outside observer. Curious thing that I noticed: after the Brexit referendum was won by the "leave" side and first months of political confusion in the UK followed, elsewhere in Europe anti-EU parties dropped in popularity among public.
It's like Brexit served the EU by uniting its members.
But a ban can be expected, as Chinese government enforces a system that allows only pre-approved games to be available to the country citizens. Chinese gaming companies too had been hit with bans.
I wonder how many people in China know facts about their country's labour camps and Xinjiang policies and still find that acceptable, not considering this a genocide.
> If Swift was a better designed language, it would have taken over by now.
If you look closely at the most used languages in different domains right now it'll become clear that the design is not what led to their wider adoption.
Search around, there are projects on GitHub which are using result builders for the web. SwiftUI is a result builder too. Not a web developer, so can't tell if those projects are really useful.
Read on the news that this kind of tracking with AirTags is used to steal cars. A car thief attaches it to the target vehicle, and then simply arrives to the place where it is parked overnight. The thief removes AirTag and then waits for an opportunity to steal the car.
I agree, I should have worded that differently. My point is an IDE isn't entitled to have yet another runtime which is not used for core functionality just because it is an IDE.
I call it outrageous because the task itself (uploading to App Store Connect) don't require a separate runtime. It's likely an artefact from the past or convenience vehicle for whoever wrote it; another example of developer's convenience trumping user experience.
> Rust is a systems programming language. It offers precise control over data layout and runtime behavior of the code, granting you maximal performance and flexibility.
I'm nitpicking, but it's due to considering the difference important for some unsuspecting programmers: having control over data layout and runtime behaviour doesn't grant you maximal performance. It grants you capability for achieving minimal overhead, which is connected to, but a different thing from performance.