1,581 karma · joined October 22, 2022
I'd argue that falls way short of being useful and still screws over employees.
People switch jobs because they get better offers, and being forced to not only forego better offers but also get stuck with the same income while your offers get taken away from you hardly seems something that's in the worker's interests. In fact, it looks an awful lot like plain old unemployment benefits.
Nonsense. Contributing back to society doesn't even register as a concern when your employer can force you to not have any alternative to work for him under his term, and apply harsh penalties to you and your loved ones if you step out of line. These nonsensical anarchist tropes only come in play to pull the focus away from the one-sided social arrangement between employers and employees in the US which his highly exploitative and outright resembles feudalism.
This is a very ignorant take. In 2022 Amazon became the first company ever to lose $1trilion market value.
https://www.bloomberg.com/news/articles/2022-11-09/amazon-hi...
In concrete terms, Amazon's stock prices tanked over 50% in less than a year.
This is not the hallmark of a healthy company.
> These firings are coordinated across large tech companies to reduce salaries and benefits, make employees work longer hours, and in general shift the power away from employees and back to the executives.
Your conspiracy theory ignores the fact that until very recently all companies were on a hiring binge without having any business case beyond "growth", not to mention that they are moving jobs overseas for years replacing highly paid engineers in the US with modestly paid engineers in India and Europe.
Alexa was described as "a colossal failure" which lost 10 billion dollars last year alone.
https://arstechnica.com/gadgets/2022/11/amazon-alexa-is-a-co...
18k is huge because Amazon has been killing off entire teams, managers and all, instead of doing the typical Jack Welch decimation tactics.
Amazon has been cutting teams that either could not justify their existence or worked in money-losing investments. Alexa was a very public project getting the axe.
This is just ignorant speculation from your end. Amazon stopped all hiring rounds over a month ago and even rescinded open offers, and that hasn't changed since Andy Jassy announced the company was going to start the unprecedented firing rounds.
I don't think this is an informed take. Amazon not only cancelled all hires but also increased the number of employees they want to fire. From the first time in the company's history, they explicitly announced they were going to fire people in a purely cost-cutting approach and in a way that was not tied to employee performance.
If anything, this signals that Amazon changed radically it's corporate strategy from a growth-oriented strategy to a consolidation one. This has strong implications on the company's revenue expectations.
If you're consuming dependencies which were never updated in the past decade then you have more worrying problems to deal with than porting your code to python3.
That's not what it means at all. Being out of spec means the spec explicitly stating that a request with a body should be reject. If the spec does not state that a request with a body should be rejected then you are not required to reject a request which packs a body.
That's what "breaking changes" and "backwards incompatible" means.
What exactly is hard to grasp?
> So you ended up w a chicken and egg problem.
You really don't. Your code and your upstream dependencies need to be ported to python3. Once your dependencies are updated, all that's missing is you doing your job.
Python2 has been on the path to deprecation for how long? A decade?
You're fabricating problems where there are none.
> Your comment is a perfect illustration of the issues. Lots of user blaming.
There is no issue. When I had to port projects to Python3, I just ported them. No drama, no hangup. You're pretending there were problems where there were none, and you're throwing a tantrum when this fact is pointed out to you.
There is really no justification for this. It's high time people like you stop making up excuses and start to own up their misconceptions, misjudgements, and mistakes.
Some projects were rewritten from scratch in entirely different tech stacks in less time the likes of you complained they could not update their projects from python2 to python3.
I feel this take is outright wrong. Python provided it's 2to3 tool[1] which took care of the bulk of the work required to port Python2 code to Python3. The only code that was not supported was eggregious errors in the code that worked by coincidence, such as handling bytes as strings and vice-versa. Porting old code to Python3 is a breeze that consisted of running 2to3, run tests with python3, and if anything breaked then just touch up the code to get it to work. I know it because I personally ported half a dozen projects throughout the years.
I'll go as far as to claim that most problems porting old python code to 3 were either upstream dependencies dragging their feet or internal human/organizational issues.
That's not what your quote says.
Not having a defined semantics does not mean if is not supported. Just because some implementations fail to support GET with a request body that it does not mean all implementations should interpret it as a malformed request.
I can roll out a service with endpoints that require GET with request bodies and it would still be valid HTTP.
This take is outright wrong. Non-native/webview-based apps are only a tolerable option if your goal is to maximize the number of platforms you cover with the same code base and skeleton crew dev team, at the expense of forcing users to endure subpar user experiences.
Not really. By "putting up a benchmark" I mean an objective and verifiable standard set of performance tests that everyone interested can contribute their best effort.
I means nothing if you roll out a cherry-picked ad-hoc test that compares a corner case of your best effort to a half-assed underperforming implementation of a competitor you chose because it suits you best.
There are standard benchmarks out there, which were already mentioned in this discussion. It takes virtually no effort to roll out Tamagui's best effort. Not using those actually requires more effort than using them, which casts doubt over the validity of self-serving cherry-picked ad-hoc tests.
I feel this sort of approach lacks honesty and fails to be objective. Anyone can cherry-pick a customized test where their stuff comes out as the best of class, no matter how underperforming it is.
To have a proper apples-to-apples comparison, standard benchmarks are the way to go. Everything else sounds like snake oil and hand-waving.
Not really. Just put together a benchmark and let it speak for itself.
Indeed, this pseudo-accuracy seems pointless.
The only relevant conclusions that taking the temperature can deliver is whether, a) there is no fever, b) there is a mild fever not requiring major concern, c) there is a major fever and extra care needs to be taken. No one in their right mind would classify these differences based on sub-degree differences in temperature.
You failed to address OP's point.
OP wondered why would he, or anyone, subject anyone else to a steep learning curve if there are no meaningful advantages to be gained.
As OP mentioned:
> Take backend dev for example: unless you're trying to squeeze the last drop of performance from your CPU, most concurrency issues are usually dealt with at the middleware level (DB, Queue, Nginx, etc), and most performance issues are usually I/O related.
Why do you believe that doubling down on a whole new programming language and tech stack would help address the fact that you do not benefit from any of it's sales pitches?
Honestly, your comment reads like a boilerplate reply to any criticism of Rust that presumes Rust's only problem is it's developer experience caused by it's learning curve but once that's behind anyone it's somehow the ideal solution for any imaginable scenario.
It might be easier to visualize the energy waste by framing it as burning through a 48 car long train full of coal each and every single day to run Bitcoin mining alone.
What exactly leads you to believe you can tell what 99.9% of all websites need?
Unless you believe 99.9% of websites are only accessed by your upstairs neighbors, CDNs provide a couple of important business and operational advantages.
Just to illustrate how wrong and misguided your personal assumption is, CDNs are primarily used to cut down latency, which in accesses from other regions can easily go beyond 300ms. Unless you somehow think that it's ok for your users to be subjected to a bad user experience, a basic CDN service is all you need to employ to lower those latencies by an order of magnitude.
Supporting only some features of a spec means that they do not conform with the spec.
Msvc is still stuck with C89, and it won't budge.
You're only commenting on your personal belief of how your ideal static analyzer would magically work to meet your expectations.
This doesn't correspond to how static analyzers work in reality.
Unless you can point out a static code analyzer which performs the sort of check that complies with your personal beliefs, it will remain firmly in the realm of practical impossibility.
C is now what? 5 decades old? Wouldn't that be enough time for anyone to roll that out if it was in fact feasible?
Nonsense. Nothing forces you to use tools outside of your workspace. CMake just requires you to set CMAKE_<LANG>_COMPILER_LAUNCHER[1] to point to a compiler launchers, which can be anywhere where you see fit, including a random path within your workspace.
People try too hard to come up with excuses for design flaws.
[1] https://cmake.org/cmake/help/latest/prop_tgt/LANG_COMPILER_L...
> One of Bazel's most powerful features is its ability to use remote caching and remote execution.
What's the value proposition of Bazel when build systems like cmake support this out of the box with third-party tools like distcc and ccache?
Totally this.
We can't pretend that the likes of Amazon et al haven't been repeatedly caught being openly hostile and extremely agressive towards any semblance of a labour rights organization within their workforce, with union busting strategies being discussed, planned, and executed at the VP level. They went as far as executing smear campaigns in the media targeting labour representatives and activists.
No one can claim that unions are in decline due to some unavoidable law of nature when huge multinationals once led by the richest man in the world invest so much time and effort and money at the VP level to sabotage them.
I feel this is a self-serving cynical take that's in line with the pump-and-dump aspect of crypto: there's this despair in trying to portray all crypto as legitimate investments and businesses when they are all far from it.
This is a red herring.
It's irrelevant if anyone feels that the 3rd or 4th or 5th dose of Pfiser's increases health risks. The problem is the misrepresentation of these findings. You cannot in good faith jump from "a residual number of people experience health issues when taking the 4th or 5th dose of Pfiser's vaccine" to "do not take any vaccine at all ever or you'll die" specially when they deny that COVID poses a threat and already killed over 6million people.
You're talking about health concerns of taking a vaccine when not taking the vaccine poses a far greater threat, and somehow that's left out of the equation. That's the problem: the disingenuous misrepresentation of the problem.