> Because if there are no material consequences for wrongdoings, they probably would not care. And there are very few kinds of actually material consequences for big companies. One of them being a really hefty fine.
In mono/oligo-poly situations there's no really such a thing as "a really hefty fine". Either the cost will be happily trickled to the very public that are being wronged or the fine is effectively unsurvivably hefty, which noone would levy against a too-big-to-fail entity.
Look at the recent fine for Meta for example. Settling a case against one of the core monopolic drivers for a couple percentage points of early revenue is peanuts. I can't believe the exec suite[-s] are thinking anything else than "which anti-consumer behavior can we buy indulgence for?", they would be stupid not to at these discounted rates.
I'm half joking here, but at this point it feels like the only reasonable way to instill some fear against building Torment Nexus and cyberpunk dystopia would be personal criminal liability of the boards and exec suites that is impossible to settle.
While this 1/2 typology is incomplete, diabetic ketoacidosis is a phenomenon generally relevant to type 1 family of conditions.
Normally (even with pure type 2!) glucose-ketone levels move in opposition: to put it simply ketone production is activated by low insulin, which is activated by low glucose. Ketone bodies are then consumed instead of glucose or excreted and generally homeostasis ensures that ketone levels do not approach anywhere close to ketoacidosis levels.
In cases where insulin production is broken (Type I diabetes, monogenic diabetes, mody) despite exogenous carbs raising blood glucose levels ketone body production is still active, however in most cases glucose is the preferred energy source, which leads to broken homeostasis of ketones, ketones accumulating and resulting diabetic ketoacidosis.
Type II family is characterized by high insulin. Some call it insufficient insulin, some call it insulin resistance, but the result is that insulin remains high and ketone production low. Regardless if the person is nominally healthy or has insulin resistance, the only way to trigger ketone production is to get insulin low for extended period, which is caused by lack of exogenous glucose. So either ketogenic diet or full-blown fasting.
Advanced and prolonged Type II diabetes (even if treated with insulin) can cause insulin production to drop along with insulin resistance, so the patient could develop Type I-like symptoms and risks, including DKA.
> There is little indication that in 2028 situation will be any better unless something drastic happens like AI crash.
China.
This market situation is a perfect storm for chinese manufacturers to step up. They don't have to chase latest-and-greatest, price-performance is one of the strongest demand drivers in consumer segment. They need a viable alternative, offer it at a reasonable price - which is much easier to achieve under current heavily inflated conditions - and that would quickly entrench them as a household brand.
Remember, it's not that there's no chinese lithography tech at all, it's just not advanced enough to yield mass production silicon at commercially viable prices. It might be the case that at current market conditions this caveat does not hold and all they need to do is ship. Even if the current prices mean they do it at break-even it would still be an enormously massive win.
Again, they don't have to compete at the flagship level from the get go, they need something commercially viable. There are tons of Chinese companies in the west and probably even more western on the outside chinese white-label goods. Chinese government has enough weight to push domestic silicon on those companies to create domestic silicon industry that can make the unit economies work.
All in all, there is a very likely scenario where this current AI boom and the resulting crunch on silicon supply creates a competitive silicon industry in China. If you think something in the realm of "I would not buy chinese silicon even if it was cheaper" it does not matter. Look at smartphone market share outside of USA, Japan and West Europe: in majority of the world Apple+Samsung barely touches 50%. What this "rest of the world" lacks in individual purchasing power it more than makes up for in numbers.
Even if somehow you had the super hero ability to create this silicon out of thin air and even double it, I'd argue that it wouldn't drive down prices.
Simply because both the AI datacenter's need and their ability to pay is bigger then the consumer market. So far it seems that the more silicon you throw at AI, then the better your reasoning output. So the cheaper the chips, the more these datacenters will buy. Arguably they would buy even more because then you can tell investors that you have more powerful models (due to more compute) and your price per output is cheaper (because average hardware is cheaper).
1. That a new player would offer enterprise level product, instead of consumer grade. IMO it's very likely that if such a scenario unfolded, the market would be segmented into enterprise/consumer not only at the product level, but at the supplier level too. At least initially.
2. That AI compute demand is essentially unlimited AND silicon production capacity is and will remain bottleneck in datacenter buildouts. IMO we are much closer to the point where physical infrastructure becomes the apparent bottleneck than it would seem, IF political climate allows. Datacenter buildout is THE talking point in Ohio elections and if the dems win, datacenters will become THE talking point in the whole USofA. In just a couple of months the landscape they are operating in could become very different.
Isn't too early to see if the Gigadatacenters will really pay off? I'm not trying to be an AI doomer here, but I thought the new really large DCs are just not yet online.
> I think Western people still call this situation “outsourcing” when in reality what is happening is that China is better at manufacturing than everyone else, and they’re starting to be better than everyone else at design and engineering, too.
The media to this day portrays China as if it was 80s. Yes, at that time it was an open-air manufacturing plant. You can run rudimentary floor operations with high school educated workers, but you still need trained engineers and managers to run the operations. Exporting engineers quickly became impractical, which led to local engineers getting trained. At some point the training became the bottleneck so local educators were trained. And so on.
Over the years, China has built the entire industrial pipeline: all the way from education and vocational training, to scientific research, to local engineering houses. Remember, the people who built Shenzen are now retired. Or to put it into perspective, China is currently at roughly similar age of industrial boom as post-WWII USA was in... the late 90s - early 00s.
"The West" had a head start with regards to IP and China is indeed fighting an uphill battle there, but they have a huge domestic market to grow the companies out. The proud "Designed in X, made in China" things are being replaced with white-label "made in China", where "designed in China" is implied.
Do you have a robot vacuum? It's probably Roborock / Dreame / Ecovacs, not even some western branding.
The overarching argument in this article seems to be sort of chicken and an egg.
> 4. No experienced developers
Well, with C you need experienced devs that are also EXPERIENCED IN C. You can write C that compiles but is all kinds of incorrect, usually subtly. Any new language that works with the dev on writing correct code or outright refuses to compile with incorrect code (hinting at Rust here) cracks this egg a bit.
> If you want to target some obscure platform, then likely it's assuming you're using C.
Some (most?) obscure platforms offer a fork of GCC, yes. With LLVM frontend becomes less and less relevant. This particular chicken and an egg is being broken with or without a successor to C.
> Any C alternative will be expected to be on par with C in performance. The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable. This leads to a strategy of only having checks in "safe" mode. Where the "fast" mode is just as "unsafe" as C.
This argument is circular. There are indeed some scenarios where you do absolutely need "macro system for assembly" to do some weird shit, but typically that is a relatively small part of the whole project. Unsafe modes help tackle this small need. The argument reads like needing C-ish language for some little parts of your project requires to use C-ish language for the whole project.
> 3. Programmer productivity
This whole argument is weirdly focused. In my experience, a huge chunk of effort is spent on rework. Any language that improves turnaround rate improves productivity on feature level. The argument again assumes that devs manage to produce correct code without turnarounds (which is rare in practice even with highly experienced devs) and therefore any new language would increase turnarounds. Safety and productivity features are usually designed to increase quality without expertise-floor.
Yeah, it's not that the hurdles pointed out in this article are wrong, but IMO the jump from "it's very hard" to "it's impossible" isn't convincingly argued. In discussions of the future of C, something along the lines of "C is never going away" is frequently said, which I think is both right and wrong, depending on what precisely you mean by "going away". If you ask me, C is not going away in the same way that Fortran never went away: it's still hugely important for numerical kernels used extremely widely every day, and software like sqlite will continue to be important. But for C as a culturally defining language in computing, I think the tide is already turning.
> Any new language that works with the dev on writing correct code or outright refuses to compile with incorrect code (hinting at Rust here)
I've started writing Rust in the past year and... honestly... I LOVE it.
But what kept me away from Rust for a long time is this talking point of rejecting incorrect code which is so obviously wrong it made proponents of Rust sound very cultish to me.
Rust cannot prevent incorrect code, nor is this possible (halting problem).
What Rust can do is enforce a very specific type of correctness, which may be termed resource-use-correctness. Basically it can enforce that every resource that is used, is properly opened, is properly accessed, has (one writer) OR (multiple readers and no writer) at a time, and is properly closed. It can do this for memory, files, sockets, as well as arbitrary constructs of your choice.
This ability is extremely valuable!
But it is also quite easy to write incorrect buggy programs in Rust, for the very simple reason that it is very easy to write incorrect buggy programs that do not misuse their resources.
I resisted Rust for a long time too. I’ve been using C++ since 2002 and always liked it especially with the modern additions. I liked the idea of Rust early on and even tried it in little amounts and it seemed nice enough, but then over time it just felt over complicated for not enough payout.
Until I learned it for real and forced myself to overcome the hurdles. Now I love it and find it hard to go back to C++. Why would I want to use any language that doesn’t prioritise safety!? Yes Rust can be complex, because things that are safe sometimes can’t be proven to be safe, and then you need a mindset shift to structure the code in ways where it can be proven safe (or if you absolutely need, unsafe lets you isolate the bits that you have to prove yourself. Many people think what’s the point of rust if it has unsafe, but they fail to understand that 100% of your code in other languages is in a rust unsafe block, while in rust at least only the smallest surface needed has to be).
Anyway, yeah, I’m a convert. As for your last paragraph, it’s true, memory safety (and concurrency safety etc) does not mean bug free. But it does eliminate one kind of common high impact error.
I think more recent languages also provide abstractions that reduce the frequency of off-by-one errors. Type systems also seem to have improved.
Unfortunately, even having tools that eliminate simple errors (like spell checkers and grammar checkers in ordinary writing) does not remove reasoning errors or clarity/conciseness issues.
(Efficient resource use is another dimension besides correctness and maintainability. Using an O(NlogN) method versus O(N×N) may be a mistake when N is small, but tools may lack the domain or profiling knowledge to detect such a mistake. Programming languages also seem to generally lack a way to express the importance of tail resource use, so even with profile information a tool might optimize for mean resource use.)
I think more recent languages have also attempted to increase clarity and conciseness by abstraction and consistent syntax. A newer language may also have more idiom consistency (some of the natural idiom divergence may be less more recently with easier communication -- the Internet functioning like cheap books did for spelling?).
I am not a programmer, but I do like thinking about such things.
> But what kept me away from Rust for a long time is this talking point of rejecting incorrect code which is so obviously wrong it made proponents of Rust sound very cultish to me.
In discussions regarding testing and static vs dynamic languages, I like to emphasize the point that with static languages you get some "tests" for free: the compiler enforcing the contract will "test" that you are not passing in string for integer. With e.g. Python if you want to be defensive and on the correctness side, you need to implement poor-man's type restrictions and tests for the unit so it behaves sensibly with call-site being incorrect.
Does it sound cultish to you to insist on static type checks when e.g. writing Python? There's quite tangible value in that.
> Rust cannot prevent incorrect code, nor is this possible (halting problem).
Yes, nothing will prevent analyst/PO from misunderstanding business requirements, nothing will prevent dev from misunderstanding the technical requirements. Or not thinking things through. Errors on this front will always turnaround.
Correctness in this context refers to programmer's and compiler's understanding of code being aligned. Correct code does what it is supposed to do. Rust takes type safety and elevates it to a next level, ensuring reads, writes and object lifetimes are correct.
Of course, but many languages do many of these things, and have for decades. C is an outlier for not having them, and many big apps use C++ over C for this reason.
Rust's contribution is static resource-use-correctness. Of course, it also implements the other features very well. But if you do not talk about these things in precise terms, it will be harder to convince people to embrace Rust adoption.
Thankfully, Rust is not doing bad for itself in terms of adoption, so what do I know! :)
But it is what kept me from using it for a long time.
> Basically [Rust] can enforce that every resource that is used, is properly opened, is properly accessed, has (one writer) OR (multiple readers and no writer) at a time, and is properly closed. It can do this for memory, files, sockets, as well as arbitrary constructs of your choice.
Mojo arguably does this better, by having both implicit and explicit destructors, and forcing developers to call explicit destructors, well, explicitly. A lock's destructor must be called manually if it is marked explicit, and thus developers reading Mojo code will presumably not be in doubt about where and when the lock is released.
This is different from Rust. In the following Rust edition 2024 code, the only difference between the two examples is a pair of "{}" around the match subject, but if you run them, one of them deadlocks, due to how temporary lifetime extension is handled in Rust.
Temporary lifetime extension is a mess in Rust, C++ and Zig. It is not a mess in C, more or less, since compound literals are arguably the only feature of C that have something like temporary lifetime extension, so any problems with temporary lifetime extension in C are limited to compound literals.
Typically the wireless mice connect over noon-bluetooth wireless protocols and offer bluetooth as fallback, if at all.
Click-to-screen latency is a combination of reporting rate, polling rate and latency within the software stack. Default USB HID polling rate is 125Hz so if you don't do anything extra on top this is what you get anyway. Even higher grade "office" mice offer higher reporting rates than that, "gaming" mice can easily be 1 kHz.
> > “Do you use personal / behavioral data / usage to shape the user experience and recommendations, creating a reinforcing loop?”
> This would include everything from my Spotify recommending new music that I like to my Netflix showing me similar shows.
Spotify recommending music and Netflix recommending shows that are similar to what? To previously recommended music/shows. This is exactly the problem.
> I'm a responsible adult. I want those things.
This is a clear indicator that these things are addictive and are in fact gambling.
I’m beginning to think some people have forgotten what we’re supposed to be angry about and now we’re just angry at all things tech.
Spotify recommending new music to me or continuing to play music suggestions when my playlist runs out is in no way harmful. It improves my life. I lose nothing to it. I gain new exposure to music.
It’s fine. Let people enjoy things.
> This is a clear indicator that these things are addictive and are in fact gambling.
I assure you I am neither addicted nor am I gambling when I listen to new music on Spotify.
What are we even doing here? Is this some puritanical push against all things that people might enjoy?
The poster is implying the reinforcement at play is the problematic thing at issue, and they are assigning the word "gambling" to represent it, or so it looks like to me. I think you aren't parsing their meaning correctly because what they seem to be aiming for is extinguishing the automatic reinforcement.
You're claiming it's making your life better, ostensibly by a relative report of the hedonic response a newly introduced piece of music auto delivered to you by the recommendation algorithm invokes. The problem they hint at though is the passive nature involved. You aren't finding that new piece, it's getting pushed. That pushing incentivizes optimizing for continued engagement, an act children, intellectually and developmentally disabled individuals, as well as those in the throes of cognitive decline/impairment, are not at all well equipped to self-regulate against when pitted against paid behavioral psychologists designing maximally engagement encouraging interfaces.
The incentive, and the existence of predatible populations is the problem I take away from it. I can agree you should be free to opt-in mind, but I can also see the wisdom in a by default interface wherein engagement hacking is forbidden being the norm, and that norm coming with a minimally controversial algorithm boiling down to "chronological feed of known/subscribed to sources", followed by a link of some sort to open an interface to the recommendations.
Facebook/Insta/Shorts are absolutely not that non-engagement farming interface. Hell my grandmother toward the end was about driven mad by it, and it was all I could do to just try to remind her that just because the machine had it on offer doesn't mean she had to partake, but her community centric character made that a bit of an ordeal for her.
There is absolutely a pathological pattern to the way tech companies hunt for eyeballs to monetize, and it is a damn shame it's taken this long to start getting traction to even talk about it.
Is it helping you find new music or is it feeding the same thing it has been feeding you in a reinforcement loop? Are you really searching or are you mindlessly taking what's on offer?
> Spotify recommending new music to me or continuing to play music suggestions when my playlist runs out is in no way harmful.
In both Netflix and Spotify any real discovery is quite well hidden, nearly all of the feeds you can get are algorithmically generated for you to consume what is beneficial to them. You get an interface pretending to offer you a choice and an algorithm behind, designed and fine-tuned by behavioral psychologists to get you coming back for more. An apparently it is doing it's job so well that you keep defending it.
> It’s hard to say what causes this uninformed certainty - is it intrinsic to being trained on human writing, or something that comes from the RLHF process afterwards
LLMs are trained to produce some form of output that is NOT nothing/dunno. The so called hyperspace collapses onto something, instead of collapsing onto lack of answer tokens.
If you watch the thinking traces of just about any modern LLM, you might be surprised at how much "uncertainty" is in there. Weak models with no thinking limits vacillate back-and-forth back-and-forth on a topic for potentially thousands of tokens before gradually spiraling towards some kind of an answer. Which makes it all the more interesting that "I don't know" is so rarely the final prediction, even with so much waffling in the chain of thought.
Until the big labs decide to start adding synthetic "I don't know" outcomes to their data sets, I've been thinking that the best way to evaluate uncertainty is to have a separate LLM monitoring the conversation and asking it to classify if the agent is overstating its confidence. On the other hand I've also noticed that most models will tell you they don't know something if you specifically include it in the prompt, eg "if you don't know the answer, just say so" and/or "be clear about any gaps in your knowledge that would reduce the confidence of your response" etc. but even with the big frontier models I have noticed some quality degradation if I throw too many instructions into the system prompt. I have a little more faith in harness-level engineering than in praying to the token generation gods.
That said, there is a completely different form of "uncertainty" in which the LLM tends to place very high trust in its own prior outputs as well as user provided inputs. Again if you look at the thinking traces, these models will try very very hard to rationalize the inputs they are given, falling back to the possibility of user error only after working through several alternative possibilities, maybe even investigating data or source code in the process. And if your context is big enough, the model might just completely miss when pieces of information conflict.
reply