the whole article kinda reads like "i have a leak in the basement of my house in the pacific northwest. the solution? im moving to nevada"
i dont dislike rust at all (infact, its rustler interop with elixir/erlang is great), but the article reframing a bunch of intentionl design choices (that i would broadly argue as good design choices) in golang as shortcomings is so weird (gc, generics, error handling, etc.). especially so when they're framed in such a way to make error-prone go seem inevitable, or are directly comparing well-written rust and poorly-written go. take, for example, the section on data races. the article broadly classifies rust as data race free and golang as full of synchronization issues. and this is true if you only actually care about data races (not race conditions broadly), assume all of your rust is safe rust, and none of your golang uses any of the available solutions (atomics, synchronization primitives, channels, etc.) to data races. yes, go leaves much of the behaviour up to the programmer. this isn't a downside.
more egregiously, the article glosses over two of the biggest and, to me, most critical differences between the two language. first, go compiles FAST. i can write something and test it immediately, including stepping through the code. i dont need to context switch away from the task and can easily, and quickly, program fixes and changes and features. this is such a huge development gain that switching away from it would require an incredibly good reason. secondly, the package structure of rust offers a clear vector for supply-chain attacks. not that golang is perfect in that sense, but it has a ton of factors that reduce the likelihood, and if i'm being really picky about safety it's going to be a big consideration.
I think you've misread the article, specifically the purpose of the Brooks quotes. They're clearly not to denigrate anyone for wanting a more useful or convenient way of generating software--they're specifically about the "LLMs will obliterate software engineering as a profession" claims put forth by many LLM marketers. In fact, Brooks is never once mentioned in the "Power to the people?" section of the essay.
Generally, the whole point of the "Power to the people?" (and to some extent the "On being left behind") section(s) is to underscore the two antithetical claims made by many LLM marketers:
1. LLMs are so powerful and so natural and easy that someone with no experience can create amazing software, and
2. LLM usage is a core skill, one that if you don't begin training now you'll be left behind.
Obviously, both of these can't be simultaneously 100% true--either it's easy enough for the non-programming layperson to successfully generate software for an intentional purpose, or, LLM assisted programming is a skill you need to train to avoid professional obsolescence in modern society. So, the article disagrees with the majority of both claims, and accepts a weakened/minor portion of each:
1. LLM output is easy to generate but accurate prompting matters, and
2. when used for software development professionally, some amount of skilled human intervention does indeed seem necessary.
And now these two claims do align.
However, if professional software engineers who work with and read code constantly, armed with the best software practices to aid LLMs we can determine, cannot use modern AI tools without shooting their feet off at relatively frequent rates, certainly you'd expect the layperson who must put an even greater amount of undue faith in the validity of the results to be at extremely high-risk of foot-shooting. It's not "gatekeeping" to forewarn people against unwarranted trust in LLM output, nor is it "gatekeeping" to suggest that modern tech communicators/marketers describing an overly flowery LLM tooling landscape might be doing people a disservice.
"dont prematurely optimize" is talking about optimization SEPERATE from architecture (and how pre-mature optimization as Knuth describes gets in the way of correct architecture). nowadays, almost any optimization purely distinct from architecture is handled either by cpu arch/logic improvements, compiler/interpreter improvements, or buried in the overwhelming tide of cpu speedups, so TODAY these terms get conflated as architecture IS typically how we optimize.
Weird take--SOLID, to me (I work in embedded but have done basically everything), represents a system of design principles that mean well and are probably fine in a heavily OO environment 80% of the time but resoundingly end up prime examples of the pareto principle.
maybe, but they're burning the compute regardless. it seems ostensibly likely that reducing the ROI for compute burnt will cause less compute to be burnt long term
Elemental sodium is reactive. Ionic sodium is not, lest you blow up your dinner. Furthermore, the lithium part of a Li-ion battery isn't the flammable part, the electrolyte is.
> If you want to replace FF there is exactly one solution, that's nuclear.
> Stop acting like you care about this issue. You have never cared enough to learn about it, so until you do, stop spreading misinformation about how physics works.
It's wild for you, in particular, to take such a weirdly aggressive stance here. Zero basis in reality, just virtue signaling.
> The FDA is partially to blame for this situation: ...
> The cost of performing a New Drug Application starts in the mid hundreds of millions of dollars range and can extend into the billions for some drugs.
> So nobody could feasibly introduce it to the market here without investing $500 million or more up front. At that price, your only viable option is to stick a big price tag on it and try to milk that money back from insurers.
It's interesting that you seem so passionate about this because you're totally incorrect. The cost of a NDA for a novel prescription drug requiring clinical data (the most expensive application) is ~$4.5mil. In fact, the estimated TOTAL revenue to the FDA from ALL PD application fees in FY 2025 is ~$1.3billion (or, just under 300 novel prescription drugs). So, obviously, FDA fees can't be as much as you're claiming.
What you're actually describing is the total cost of the entire drug development pipeline (research, design, lab costs, chemical costs, application costs, marketing costs, etc.) to develop a brand new, novel drug. And it's only ~$200m, increasing to $500m if you include dead ends / failures in the process, and ~$900m if you include both failures and capital costs--yep, that's right the capital costs alone are almost as much as the entire rest of the drug development pipeline.
any commercial rtos shop where QNX may be appropriate is either using 1. some wacky expensive proprietary rtos that you've never heard of, 2. freertos or 3. real-time linux depending on what they need. asking what makes QNX a compelling rtos when freertos exists, is widely supported and used, and has an MIT license is a very valid question.
further, no one in embedded actually cares what RTOS you used. they are all similar enough that you won't get stuck if it's a brand new RTOS
Without Oxford comma: "We invited JFK, the stripper and Stalin." [three distinct items in the list]
With Oxford comma: "We invited JFK, the stripper, and Stalin."[two named items in the list with an appositive affirming that we're talking about JFK the stripper and not the former president]
Same here--same for some members of my immediate family as well. Had a few days in a row where I got virtually no sleep and wasn't tired, either. Haven't had any symptoms and am in a low-risk area though.
No, I don't think harassment in any form is acceptable.
I do think the case of Hsu is worth using as an example here: an intra-university conflict; a group of grad students is petitioning for a professor that they believe is actively harmful to the institution to step down as director of research. Now, I don't think it really matters what you or I think about any of this--whether or not we agree with the students or the prof is immaterial. This is an issue for the university, the students at the university, the professor, and any professional relations the professor has within his field of academia.
If I'm a student at the school, and I'm pro-grad student faction, I'd probably be rightly annoyed and mighty curious at a pseudonymous blogger so fervently involving himself. Why the pseudonym? Why the support? It would behoove me to look into this person, seeing as, from my perspective, he is signal boosting an erroneous cause via his immensely popular website.
If I'm a professor at the school, and I'm pro-prof faction, I'd probably be rightly bewildered and mighty curious at a pseudonymous blogger so fervently involving himself. Why the pseudonym? Why the support? It would behoove me to look into this person, seeing as, from my perspective, he is signal boosting, albeit for a good cause, via his immensely popular website, with no apparent reason to do so, seeing as how he doesn't seem to be a geneticist or faculty. It would definitely give me pause, to say the least.
I can think of things even in my personal life or business where, if an outsider were involving himself trying to "signal boost" a resolution (even if in my favor), I think I'd very rightly want to know the motivations and identity of said person.
The above examples don't illustrate that he should be identified, rather, that he's presenting people with a compelling reason to want him identified. I don't think he should be ID'd, but if a campus paper wrote an OP-ed about it, I'd have a hard time faulting them.
I don't think anyone should harass anyone else, which I think is somewhat what Scott has been doing (perhaps for a righteous cause) with this affair (as, by nature, signal boosting pro-prof draws some fire upon the grad student faction in question), so his response here rings a little bit hollow to me. But, to be crystal clear, even if I think Scott is using his platform to ever so slightly browbeat institutions via his followers (in the most mild sense & with the best of intentions), I still think the NYT is very much clearly in the wrong.
Unfortunate, for sure. The NYT has no real reason to post his name (as far as I'm aware--the tone of the article could affect that conclusion), so I'm not really sure why they'd dig their heels in here.
Though, he really does post a lot of personal and identifying information on his blog--literally any motivated party could find his name very easily. I thought "maybe he doesn't want his real name to link to his blog if a patient googles it"--but, it already does that. In fact, it's a suggested search in google!
Ultimately though, in some respect, I do think Scott's trying to have his cake and eat it too a bit here. I think when he starts trying to influence certain events in the real world; eg. like his Signal Boosting for Hsu to give an example within the last week, where he takes umbrage against the Grad student organization at MSU to drum up support in defense of Prof. Hsu--whether or not you agree with Hsu or you agree with the graduate students at MSU, Scott is decidedly an outsider attempting to exert his influence. People have mentioned that these sorts of actions legitimize the "fair play" of the NYT revealing his real identity, and I'm having a hard time finding umbrage with that statement.
I don't think the NYT should post his full name but I also do think Scott has been playing fast and loose; both with revelatory facts about his identity and by putting himself in situations where there are legitimate reasons for blog-outsiders to inquire about his real identity. Hopefully there will be an amicable end to this conflict.
> So I never saw any indication that this was malicious on Apple’s part.
They intentionally slowed down all iPhones in the face of more user-friendly options to fix an issue a minuscule percentage of people had. I think you can choose to view this as a solution, but I'm leery of anyone who thinks this was an appropriate solution.
> They determined this happened because aged batteries were not capable of delivering peak current anymore and the CPU was “browning out” under heavy load.
This is kinda true but ultimately more misleading than insightful. It makes it sound like it's just the batteries' fault and nothing can be done. Aged batteries are perfectly capable of delivering all the peak power necessary for operation. The only time it's possibly an issue for the LiCo oxides the iPhone uses is at a low SoC after a relaxation period (which is amplified if the battery itself is physically cold). So, in a perfect storm of events you'll have a phone that will die from 10% SoC.
But then your SoC isn't really at 10%, innit? Your SoH is actually lower, so your SoC needs to diminish faster to accurately map to your reduced capacity. SoC isn't a mystery either. Because this issue is prevalent after a relaxation period on the LiCo batteries, you can get pretty accurate SoCs from simply reading OCV. Remember, OCV:SOH mapping is only difficult for non-Cobalt Lithium chemistries, and even then often only in the middle range. Reductions in SoH speed up passage along the OCV:SOC curve, not chop the ends off--and the ends are the most prominent.
> A phone that is moderately slower is still more valuable than one that randomly crashes.
There are other things Apple could have done. Like, actually accurately report the SoC. Or reduce screen brightness at lower SoCs. Further, it's not "randomly crashing"--it's shutting off at low charge% (but higher than people would expect).
I don't know if it was malicious, but if not, it's a surprisingly stupid fix from an otherwise brilliant engineering team, and it seems the judge agreed.
> Firstly, they only slowed down older phones to prevent them from crashing as they had less and less reliable battery draw
I see this posted a lot and I honestly just don't buy it.
Processor power draw for most high-priority OS tasks (eg: keyboard input) are virtually zilch compared to keeping the screen lit for that much longer.
Everything says this happens to older phones, not phones with high usage. If you get the battery replaced--will Apple speed up the phone again? If I am on my iPhone 24/7 and constantly discharge down to 5% SOC, how come Apple doesn't slow down my phone more than someone with scarce use?
Even unreliable power draw makes no sense. You may be not able to predict the SOC from the OCV of the cell as accurately as SOH diminishes than when it's 100%, but cell phones largely use lithium cobalt oxides which have well-defined OCV:SOC curves! There should be no need to guess how close to a low SOC you are--you can just read the OCV.
Your point about unsafe pointer handling in Rust is specifically what dissuaded us from using it in an upcoming project. It really feels bad prepending all of the code that you actually care about being safe with `unsafe`.
i dont dislike rust at all (infact, its rustler interop with elixir/erlang is great), but the article reframing a bunch of intentionl design choices (that i would broadly argue as good design choices) in golang as shortcomings is so weird (gc, generics, error handling, etc.). especially so when they're framed in such a way to make error-prone go seem inevitable, or are directly comparing well-written rust and poorly-written go. take, for example, the section on data races. the article broadly classifies rust as data race free and golang as full of synchronization issues. and this is true if you only actually care about data races (not race conditions broadly), assume all of your rust is safe rust, and none of your golang uses any of the available solutions (atomics, synchronization primitives, channels, etc.) to data races. yes, go leaves much of the behaviour up to the programmer. this isn't a downside.
more egregiously, the article glosses over two of the biggest and, to me, most critical differences between the two language. first, go compiles FAST. i can write something and test it immediately, including stepping through the code. i dont need to context switch away from the task and can easily, and quickly, program fixes and changes and features. this is such a huge development gain that switching away from it would require an incredibly good reason. secondly, the package structure of rust offers a clear vector for supply-chain attacks. not that golang is perfect in that sense, but it has a ton of factors that reduce the likelihood, and if i'm being really picky about safety it's going to be a big consideration.