934 karma · joined November 14, 2021
Hard disagree. VS makes code harder to navigate than any other popular IDE out there to the point where even vscode is more intuitive and capable, it's extremely slow at that too, and makes even the tiniest change to a build config something that requires jumping through a myriad arcane menus.
Having used other IDEs to develop Java, C# and C++ code, the only explanation I can find to explain Visual Studio's adoption, besides privileged access to Microsoft's emergent technologies and frameworks, is the boiling frogs analogy.
> If you are having to fight with VS, then you may not be using it for one of its main use cases.
I guess that writing software and building projects are not Visual Studio's main use cases, then.
I doubt this assertion is grounded in reality. Sites that resort to puns from cc TLDs like lobste.rs don't suffer from name recognition problems, and no one ever had any problem remembering twitch.tv.
The longest vanity TLD I could find was .travelersinsurance. Two dozen characters are nothing more than a rounding error in the 2k character limit. You routinely pass 10 times more characters in path and query parameters than you do in the domain name.
Also, how often do people type in URLs instead of clicking links?
Also, keep in mind that some browsers are starting to hide path and query parameters in the address bar and instead only show the domain name. I presume that makes domain names and TLDs more relevant in terms of name recognition.
One of the original TLDs is .arpa, and I don't see any of that uniformity in a world where second-level domains like .co.uk domains are pervasive.
> Additionally, I always found it interesting how the .xxx TLD never took off (was essentially DOA)
The usecase driving .xxx was not from site operators but from third-parties seeking an easier way to censor porn sites.
https://en.wikipedia.org/wiki/.xxx
The concept was flawed from the start given the same site can be served through multiple domains, and it relied on site operators located in any jurisdiction from any corner of the world to voluntarily serve their sites thorough that TLD.
I disagree. No one was born recognizing .com domains, and outside of the US non-.com domains are already quite mundane. In fact, FANGs like Amazon employ cc TLDs quite extensively to segregate marketplaces, and they do just fine.
> No, the issue with the new/generic/vanity TLDs is that they've lost all meaning.
This assertion has no bearing in reality, specially given domains like .io, .icu, .info, .site, and even .aws.
This is the crux of the error you're making. Exceptions are not about control flow. Exceptions are a transparent and clean way to handle exceptional events. Exceptions are not intended to, say, handle the status code of a HTTP requests. Exceptions are intended to handle exceptional and potentially unrecoverable errors in a safe and controlled manner, such as failing to allocate memory, regardless of where and how they pop up.
Therefore, suggesting classical C-style return codes or specialized monadic types to handle results as alternatives to exceptions completely misses the whole point of exceptions and, more importantly, all the classes of problems they are designed to eliminate.
I run about half a dozen web apps on a single node on Hetzner with Docker swarm mode + traefik ingress + whatever the web apps need.
Any app I have is deployed in seconds as a docker stack. I treat my Docker swarm node as cattle, and I have an Ansible script to be used in case of emergencies that deploys everything from scratch. The Ansible script takes, from start to finish, only a couple of minutes to get everything up and running. I can do this with zero downtime as I have an elastic IP I can point at any node at will.
If I wanted, I could optimize everything even further, but it's already quite fast. In fact, I can get a new deployment on my Hetzner setup up and running faster than I can get an EC2 instance available in AWS.
Proponents of big cloud providers as the only viable option typically have absolutely no idea what they are talking about regarding availability, redundancy, and disaster recovery. It's mostly resume-driven development seasoned with a dash of "you don't get fired for picking IBM".
What if your server is already compromised? Doesn't that approach ensure your server remains compromised after you pressed the big undo button?
Enough with this cargo cult belief system. Even if your choice of bicycle has training wheels, you can still fall down and scrape your knees if you don't know what you're doing.
I mean, Rust already has a few CVEs for use-after-free vulnerabilities, which this cargo cult swears are rendered impossible.
Just stick with your personal choice of worktool and own it. It's not the guardrails that stop you from crashing, but the way you drive.
If your goal was to use that poor example to support the idea that people stick with subsets of C++ because of reasons, that example failed to support the assertion. Thus it makes no sense to stick with a patently wrong observation just because it's easier to recall.
Getting back to the topic, as far as I know there are only two features of C++ which are up for debate regarding their adoption: exceptions, and template metaprogramming. The exception-handling debate only makes sense in very low-level applications and refactoring legacy exception-less code, which in practice is not anyone's case. The template metaprogramming debate typically boils down to YAGNI and the need to avoid resume-driven development. Nevertheless, both features are used extensively, whether directly or indirectly (see STL), and in general there is no reason to bother debating whether people should use it or not, unless you have very specific requirements in mind (I.e., avoid generating magical code in embedded applications, or in very high performance applications where you feel you need tight control over everything down to which instructions are generated).
If I recall correctly, Google's rationale regarding exceptions is that their legacy code is not exception-safe, and so they were faced with the choice of either rewriting critical parts of their legacy code to handle exceptions, or don't use them.
Also, their "no exceptions" rule only applied to work involving their legacy code.
I'm too lazy to find the source, but that bit of trivia was already discussed ad nauseum even in HN.
The morale of the story is that you should not mindlessly repeat any opinion without knowing the rationale and instead pulling appeals to authority to cover up the logical hole. That's how you end up contradicting even your source, just because you believed that's how the cool kids do things.
Sometimes you need to upgrade your compiler but can't/don't want to rebuild the whole dependency graph.
Because sometimes you need to import prebuilt libraries/modules provided by a third party, and you don't control how those were built.
Keep in mind that C++ does not define a standard ABI.
That makes no sense. I mean, all you need to do to check if the factory subjects workers to subhuman conditions is send someone from Apple there, look around, and ask a few questions to random employees.
And also, are you really trying to argue that Apple is able to verify and guarantee that their luxury consumer electronics products leave the plant meeting tight quality control requirements but somehow it's impossible to ensure that the same employees who met those quality control specs will have worm-free meals?
Are they, though?
I don't see people claiming that "crowded dorms without flush toilets and food sometimes crawling with worms" is totally fine if the plant makes Samsung or off-brand smartphones. What I'm seeing is a luxury brand on the defensive because their customer base learned that the workers making Apple's luxury products not only have been enduring "crowded dorms without flush toilets and food sometimes crawling with worms" but also tainted food that causes mass health issues.
What really boggles the mind is that these sub-human working conditions seem to cause downtime in their plants, which ultimately means it costs them money. But somehow even that is not enough to convince them to treat workers as if they are human beings.
The most expensive NFT to date was the result of such a fraud.
https://www.cnet.com/news/why-this-cryptopunk-nft-sold-for-5...
Relevant link: https://en.wikipedia.org/wiki/Wash_trade
I'd bet that if someone bothered to trace the wallets used in the transaction, they'll find out they start and end at the same person.
I second GP's assessment that Bazel is pretty developer-hostile if you are not Google or have Google's resources to maintain Google's build systems.
Case in point: get Bazel to consume system libraries or vended/third-party dependencies in a C++ project. This is a pretty basic usecase, but it was left as an afterthought in Bazel, and it's an uphill battle just to get Bazel to work with them.
I don't doubt that Bazel can be usable if your entire world is locked tight in repos you control and were all forced to migrate to Bazel. It's the same thing with GYP, another developer-hostile build system spawned there. However, that is not how the world outside of Google works.
The only way I see Bazel become relevant and usable for non-Google/FANG-size orgs is if a higher level build system like CMake supports generating Bazel code, so that all these shortcomings are brushed under the proverbial rug. However, if we get to that, are we really using Bazel, or is Bazel relegated to an implementation detail?
No, not really. It shows a list of past submissions, which of course include the corresponding discussions.
Take a look: https://hn.algolia.com/?query=System%20Design%20Primer%3A%20...
The basic principle is falsiability. It has been widely established that a sufficient condition to alter or eliminate consciousness and even personality traits is inflicting precise physical changes to the brain, such as severing pathways.
There is absolutely no evidence, let alone reproducible observations, supporting crackpot theories such as afterlifes or any form of consciousness that is not dictated by the brain.
It makes absolutely no sense to appeal to this or any other form of crackpot theories by alleging that established facts and knowledge covered by mainstream theories is still under development.
If only there was a NFT assuring it's provenance.
I'm not sure you read the article you cited, but it clearly states that the initial claims behind the "god helmet" cannot and could not be independently replicated.
Also, the underlying theory refers to "very weak magnetic fields" that are "as strong as those generated by a land line telephone handset or an ordinary hair dryer". If this had any bearing on reality, the law of large numbers would imply we'd see a relatively large number of people experiencing this effect in the wild in ways that could be replicated and experienced by anyone in the vicinity, which we are not.
So, what leads you to believe that these claims are not made up by either a crackpot or a fraudster?
This assertion is rather short-sighted and presumes, wrongly, that knowledge on a topic is already complete.
Yet, we live in a day and age when scientists are still discovering muscles in the jaw. We're talking about basic anatomy, not how neurons work.
https://news.ycombinator.com/item?id=29705819
Is it too hard to imagine that knowledge on how the brain actually works is still far from complete?
You wrote a rather lengthy post saying you disagree, mixed with an empty appeal to authority, but you provided no counterpoint or evidence or rationale or hypothesis refuting or contradicting the assertion that the mind is the brain.
If the mind is not the brain then what is it, then?
I'm not sure you hit an eventual consistency thing while you read the source you cited, but the definition of a vaccine in it does not match your definition.
A vaccine, according to the CDC source you quoted, is:
> Vaccine: A preparation that is used to stimulate the body’s immune response against diseases. (...)
Keep in mind that your personal definition of a vaccine does not match how most vaccines work, if any vaccine at all.
Your personal assertion bears no relationship with the case, and rationale, presented in the paper.
The paper's author's simply found out that shared e-bike/scooter users answered in a survey that if they did not had access to that mode of transportation then the next best option would be walking, and thus the authors proceeded to conclude that shared e-bike s/scooters are bad for the environment because if they didn't existed then people would walk and walking doesn't pollute as much.
To me, frankly, that sounds like specious reasoning. Walking is only an option in routes which are not that long and are not served by affordable public transportation with an acceptable availability. It makes no sense to depict a mode of transportation to be bad for the environment only if there is no alternative, and it makes no sense to assert that the same mode of transportation became awesome for the environment if a preferable but more polluting mode of transportation is suddenly provided.
Wikipedia defines a super spreading event as an event where an infectious disease spreads much more than usual.
https://en.wikipedia.org/wiki/Superspreading_event
The study refers to a private social event attended by 33 participants comprised of triple-vaccinated healthcare workers, where 21 triple-vaccinated attendees contracted COVID.
...said the person who hasn't died of COVID.
Meanwhile, those who died from COVID typically undergo an excruciating death.
https://www.vox.com/2021/2/20/22280817/covid-19-deaths-us-nu...
That blend of belief is shared by a subset of militants, but that's the result of the years-long propaganda campaign devised by the militant group's leadership in preparation for the election campaign.
We're talking about a política group which dedicated itself simultaneously to sabotage the election campaign by attacking voting methods believed to be disproportionally and massively favoured by other candidates , and included the preparation of a coup to overthrow the political regime to continue holding power.
The myth about fraudulent elections, which preceded the election by over a year, was made up by the militant group's leadership, and we should not interpret it as a reasonable and natural excuse to push a self-serving myth.