That felt like an indicator to me. I only switched to Linux a year or two ago and haven't mentioned it to her once, so she got the idea from somewhere else, and had enough impetus from whatever she disliked about Windows to actually go through with the change. If I was in marketing at Microsoft I'd be shitting myself over that, assuming Windows even still fits into their long term plans somehow. It's one thing for 100,000 techies to preach Linux across the web, but if random normies start using it without fanfare, that's real change.

With compiled languages you can statically infer a ton of type information without having to pepper your codebase with repeated references to what something is. Nominal typing essentially boils down to a double-check of your work, you specify the type separately and then purposely assign it to a variable, so that if you make a mistake with either part the compiler picks it up.

But those kinds of double-checks can be done for almost anything (outside of dynamic boundaries like io/dlls) without nominal type signatures in the code, as long as you jettison the ability to change types at runtime. No language as far as I can tell actually does this because we're all so obsessed with the false dichotomy of nominal and dynamic typing.

In JS everyone likes to use string unions in place of enums so let's use that as an example. If you have something that is only ever set as "foo" or "bar", that's effectively a boolean. If you receive that string in another function, make a typo and write if (str == "boo"), then in every single language I'm aware of that passes a compiler check. But it shouldn't, because the compiler has all the information it needs to statically catch that error and fail the build. The set of assignments to that variable and the set of equality checks on it provide the two parts of the double-check.

In a perfect world we'd have 10 of these "middle of the road" strongly typed static languages to choose from that all optimise for minimal type representation in their own unique way. But every time I see one of these projects pop up on HN it gets like 10 comments then disappears into the sunset because the programming community is so enraptured with the nominal type system of C and all the fucking bullshit Bjarne Stroustrup pasted on top of it 40 years ago. So we end up with this silly situation where the only things considered "safe" by the crowd are strict descendants of C/C++ with the array/pointer/string screw-ups that made those languages unsafe removed.

Adding complexity to your type system and to the representation of types within your code has a cost in terms of mental overhead. It's become trendy to have this mental model where the cost of "type safety" is paid in keystrokes but pays for itself in reducing mental overhead for the developers. But in reality you're trading one kind of mental overhead for another, the cost you pay to implement it is extra.

It's like "what are all the ways I could use this wrong" vs "what are all the possibilities that exist". There's no difference in mental overhead between between having one tool you can use in 500 ways or 500 tools you can use in 1 way, either way you need to know 500 things, so the difference lies elsewhere. The effort and keystrokes that you use to add type safety can only ever increase the complexity of your project.

If you're going to pay for it, that complexity has to be worth it. Every single project should be making a conscious decision about this on day one. For the cost to be worth it, the rate of iteration has to be low enough and the cost of runtime bugs has to be high enough. Paying the cost is a no brainer on a banking system, spacecraft or low level library depended on by a million developers.

Where I think we've lost the plot is that NOT paying the cost should be a no brainer for stuff like front end web development and video games where there's basically zero cost in small bugs. Typescript is a huge fuck up on the front end, and C++ is a 30 year fuck up in the games industry. Javascript and C have problems and aren't the right languages for those respective jobs, but we completely missed the point of why they got popular and didn't learn anything from it, and we haven't created the right languages yet for either of those two fields.

Same concept and cost/benefit analysis applies to all forms of testing, and formal verification too.

1k * 250 * 8 * a team size of 20 is about 40 mil in salary for engineering, could be low, add on their $12M testing, $4.1M just for the design (vintage Deloitte), some cloud cost blowouts and a bunch of dickhead managers and scrumlords, plus the putrid enterprise-grade 3rd party map/data system they've gone with, I bet that wasn't cheap. All up it's in the right ballpark for a typical well-intentioned trainwreck consulting project.

Wouldn't be the first project to blow out because of a bunch of enterprise Typescript, Java and C# devs that can't deliver anything.

Welcome to the Aussie tech industry.

Also, they caught the drug kingpin at the end of the show by physically following his lieutenants to a warehouse full of drugs and arresting them all on the way out. The only thing the wiretaps were used for was to build a conspiracy charge against the leader, who had been standing outside for months/years doing face to face meetings with everyone that was arrested, clearly being the one in control of every conversation. If somehow that's not enough to charge someone with conspiracy then it seems removing a small amount of freedom to change that would be far preferable to reading everyone's messages and banning encryption.

"The Wire proves the need for mass surveillance" is the dumbest take I've ever heard. It literally shows the complete opposite.

Sugar is a very indirect cause of heart attacks, everyone knows that most heart attacks are a culmination of decades of diet and exercise habits. It's still worth researching everything to do with that, but it's pretty low value research because it's hard to draw any actionable conclusions from it other than "eat healthier and exercise", which is already well known.

The research in the article is talking about a direct cause. Bacteria exists on arterial plaque, viral infection triggers bacteria to multiply, something about that process causes the plaque to detach and cause a heart attack. If that ends up being a rock solid cause and effect, even for a subset of heart attacks, that could lead to things like direct prevention (anti-virals before the heart attack happens) or changes in patient management (everyone with artery disease gets put far away from sick patients) that could directly and immediately save a lot of lives.

The post you replied to was saying that the data from the study isn't as strong as the article and headline make it out to be, which is usually the case. For this one though I'm reading that less as "it's a nothingburger" and more as "it's a small interesting result that needs a lot of follow up".

This bit has me perplexed. If you had a single message that you wanted to send multiple times in different forms, wouldn't compressing the message exponentially limit possible variation whereas expanding it would exponentially increase it? If you had to send the same message more than a couple of times I'd expect to see accidental duplicates pretty quickly if everyone had been instructed to reduce the message size.

I guess the idea is that if the message has been reduced in two different ways then you have to have removed some information about the original, whereas that's not a guarantee with two different expansions. But what I don't understand is that even if you have a pair of messages, decrypt one, and manage to reconstruct the original message, isn't the other still encrypted expansion still different to the original message? How does that help you decrypt the second one if you don't know which parts of the encrypted message represent the differences?

...right?

The problem is that GPU hardware is rapidly changing to enable easier development while still having low level control. With ReBAR for example you can just take a pointer into gigabytes of GPU memory and pump data into it as if it was plain old RAM with barely any performance loss. 100 lines of bullshit suddenly turn into a one line memcpy.

Vulkan is changing to support all this stuff, but the Vulkan API was (a) designed when it didn't exist and is (b) fucking awful. I know that might be a hot take, and I'm still going to use it for serious projects because there's nothing better right now, but the same extensibility that makes it possible for Vulkan to just pivot huge parts of the API to support new stuff also makes it dogshit to use day to day, the code patterns are terrible and it feels like you're constantly compromising on readability at every turn because there is simply zero good options for how to format your code.

WebGPU doesn't have those problems, I quite liked it as an API. But it's based on a snapshot of these other APIs right at the moment before all this work has been done to simplify graphics programming as a whole. And trying to bolt new stuff onto WebGPU in the same way Vulkan is doing is going to end up turning WebGPU into a bloated pile of crap right alongside it.

If you're coming from WebGL, WebGPU is going to feel like an upgrade (or at least it did for me). But now that I've seen a taste of the future I'm pretty sure WebGPU is dead on arrival, it just had horrendous timing, took too long to develop, and now it's backed into a corner. And in the same vein, I don't think extending Vulkan is the way forward, it feels like a pretty big shift is happening right now and IMO that really should involve overhauls at the software/library level too. I don't have experience with DX12 or Metal but I wouldn't be surprised if all 3 go bye bye soon and get replaced with something new that is way simpler to develop with and reflects the current state of hardware and driver capabilities.

fucking lmao

...they do? You can shuffle money all you want, if nobody can write the fucking code then you don't have software. I imagine it works much the same in any other field.

Do you know how fucking obnoxious it is when 200 people like you come into every thread to tell 10 C or Javascript developers that they can't be trusted with the languages and environments they've been using for decades? There are MILLIONS of successful projects across those two languages, far more than Rust or Typescript. Get a fucking grip.