waterTanuki

> The quality of health care in the US is significantly higher than anywhere else in the world.

Source, backup your claims.

Health outcomes are WORSE than most other developed countries and that's the only statistic that matters here

Nor should it strive to be a market. Healthy markets can only exist where demand is elastic. If the choice is between dying to kidney failure or enduring life-crushing medical debt, you bet I'm going to do anything it takes to get that transplant. And therein lies the problem: You *cannot* have healthy markets in healthcare. Period. Demand for healthcare is fully inelastic. Anyone arguing the opposite is either profiting off the status quo or woefully ignorant of economics.

One would hope that Microsoft will eventually revoke kernel access to these companies (see, Crowdstrike incident) eventually forcing game developers to support Linux for many popular online service games and actually stop being so lazy with anticheat. Somehow a smaller studio like Embark managed to make Arc Raiders compatible with Linux. I have 95 hours into the game and have not encountered 1 cheater. Yet a mega corp like EA can't possibly afford to support BF6 on Linux because of kernel anticheat. I put only 10 hours into bf6 and got killed by aimbots three times.

Just use pnpm. I've never once had compatibility issues with it on linux/mac/windows over the past 6 years.

I had to use Perl in a recent project to perform health checks on a container. The container authors decided not to provide /dev/tcp or curl, and I didn't want to add the extra headache of maintaining an upstream fork with curl, but they did include Perl. So I (claude) wrote a one liner script that imported the networking lib and performed the check instead.

(Side note, I know "slim" containers are all the rage these days but please please please please just put curl in your unix containers or provide a script that lets me check the container health. I don't want to spend more than 5 minutes setting this up or I'll just look for something else)

Tailscale isn't a massive corp, more like a Series B startup. And the CEO's take on LLMs is a sober one, not based on hype.

https://tailscale.com/blog/ai-changes-developers

Not a cloudflare employee but I do write a lot of Rust. The amount of things that can go wrong with any code that needs to make a network call is staggeringly high. unwrap() is normal during development phase but there are a number of times I leave an expect() for production because sometimes there's no way to move forward.

My company uses a MSFT for domains, email, office work etc. but hands all the employees (not just engineers, HR as well) Macs. I don't know what kind of places you're working for but I'm not really interested in spending more time debugging your mattermost instance or email server instead of working on the core product I was hired to work on. I agree microsoft software is a plague but good luck convincing the people with the money to use something else lol

> Chatgpt is the new way to get information on the internet, like it or not.

We aren't making it past the great filter as a species, like it or not.

> Many companies are already getting direct value out of AI.

Source that immediately refutes this claim: https://www.artificialintelligence-news.com/wp-content/uploa...

> Despite $30–40 billion in enterprise investment into GenAI, this report uncovers a surprising result in that 95% of organizations are getting zero return

They wrote their own graphics renderering library for starters, that's bundled into the editor when compiled.

https://www.gpui.rs/

I can empathize with how lazy some developers have gotten with program sizes. I stopped playing CoD because I refused to download their crap 150+ GB games with less content than alot of other titles that are much smaller.

That said, storage is cheap, it's not a mentality but a simple statement of fact. You think zed balloons their file sizes because the developers are lazy. It's not true. It's because the users have become lazy. No one wants to spend time downloading the correct libraries to use software anymore. We've seen a rise in binary sizes in most software because of a rise in static linking, which does increase binary size, but makes using and testing the actual software much less of a pain. Not to mention the benefits in reduced memory overhead.

VSCode and other editors aren't smaller because the developers are somehow better or more clever. They're using dynamic linking to call into libraries on the OS. This linking itself is a small overhead, but overhead none-the-less, and all so they can use electron + javascript, the real culprits which made people switch to neovim + zed in the first place. 400mb is such a cheap price to pay for a piece of software I use on a daily basis.

I'm not here to convince you to use Zed or any editor for that matter. Use what you want. But you're not going to somehow change this trend by dying on this hill, because unless you're working with actual hardware constraints, dynamic linking makes no sense nowadays. There's no such thing as silver bullet in software. Everything is a tradeoff, and the resounding answer has been people are more than happy to trade disk space for lower memory & cpu usage.

considering how cheap storage is nowadays nitpicking about binary size is a very weird take. Are you editing code on an esp32?

I can't imagine how frustrating it must be to be making some of the best hardware out there only to have it completely wasted on useless "liquid glass" UIs and locked down to a half-baked OS (looking at you iPadOS).

Given the common retort for why not try X project in Y new language is "it's barely used in other things. Let's wait and see it get industry adoption before trying it out" it's hard to see it as anything OTHER than a zero-sum game. As much as I like Rust I recognize some things like SQLite are better off in C. But the reason you see so much push for some new languages is because if they don't get and maintain regualr adoption, they will die off.

> The SPARK prover correctly notices that there's nothing stopping us from entering a value outside the array bounds. It also points out that the Get call we're using to read the integer from stdin can raise an unexpected Constraint_Error at runtime if you type in anything that can't be parsed as an integer.

To me, this doesn't sound like something unique to spark. Let's return to the solution example:

    procedure Overflow_This_Buffer
       with SPARK_Mode => On
    is
       type Integer_Array is array (Positive range <>) of Integer;
       Int_Array : Integer_Array (1 .. 10) := [others => 1];
       Index_To_Clear : Integer := Int_Array'First - 1;
    begin
       while Index_To_Clear not in Int_Array'Range loop
          Ada.Text_IO.Put ("What array index should be cleared? ");
          --  Read the new array size from stdin.
          Ada.Integer_Text_IO.Get (Index_To_Clear);
       end loop;

       Int_Array (Index_To_Clear) := 0;
    end Overflow_This_Buffer;

All you have done here is proven that within the vacuum of this function that the index will be a valid one. Indeed, this is even confirmed by the article author just prior:

> If we wrap the Get call in a loop, and poll the user continuously until we have a value within the array bounds, SPARK can actually prove that a buffer overflow can't occur. (Remember to initialise the Index_To_Clear variable to something outside this range!)

You have to poll the user continuously until a valid input is given. Again, I don't see how this is any different or special compared to any other programming language that would handle the error by asking the user to retry the function.

> Key word here is can. You can write correct software using any language, from raw binary to theorem proving languages, but some languages check more properties at compile time than others. What using something like SPARK/Lean/Agda/Rocq buys you is the "more" part, up to allowing you to eliminate runtime checks entirely because you proved at compile time that the corresponding error conditions can not happen (e.g., proving that indices are always in bounds allows you to omit bounds checks). That's not something the more popular languages are capable of because their type system is not expressive enough.

But I think the discussion here is about Rust, Ada, C/C++ no? The type system in Rust, Ada, and C++ are all robust enough at least to accomplish this.

> This seems contradictory, especially when considering that type checking is creating a formal proof?

Exactly! This is the root of my issue: you can accomplish this magical "proof" you speak of without using SPARK or Ada or any special "contract" language.

But isn't the entire point of rust's verbose type system to declare valid states at compile time? I don't exactly see how this can't be proved in rust.

This is the smoking gun for me:

    procedure Overflow_This_Buffer
       with SPARK_Mode => On
    is
       type Integer_Array is array (Positive range <>) of Integer;
       Int_Array : Integer_Array (1 .. 10) := [others => 1];
       Index_To_Clear : Integer;
    begin
       Ada.Text_IO.Put ("What array index should be cleared? ");
       --  Read the new array size from stdin.
       Ada.Integer_Text_IO.Get (Index_To_Clear);

       Int_Array (Index_To_Clear) := 0;
    end Overflow_This_Buffer;

What I am asking is what exactly is formally proving from 1st principles? Because to me this looks no different than a simple assertion statement or runtime bounds check which can be performed in any language with if statements & exceptions.

How did you prove that no one could just put in an arbitrary integer into that function? Does it fail to compile? Then you're just making a custom type which enforces valid state which, again can be done in any language with a rich type system and if statements.

If I might be more blunt: formal proofs in the field of programming appear to be nothing more than mathematicians trying to strong-arm their way into the industry where they aren't necessarily needed. Formal proofs make sense when you're trying to come up with new formulas or studying the cosmos, but they make no sense when you're trying to predict how bits will behave on a computer, because for the most part that is a solved problem by languages themselves.

> If you’re prepared to look at alternative programming languages to avoid the costs and risks of C/C++, SPARK offers an opportunity to go much further than Ada or Rust. SPARK, which is based on Ada, offers industrial-strength formal methods: an opportunity for you to prove mathematically that your software is safe and secure. This paradigm shift in software development methodology offers significant cost savings for high-integrity software.

Forgive me if I sound naive but I always found it a bit weird how something like this is touted as a strength of Ada, but never actually demonstrated in comparison with a heavily typed language like Rust. Regardless of the language, you cannot write some special program that guarantees an input will be valid if it comes from an external source or a human. It is simply impossible to prove this at compile time. What you can do in rust, and other languages, is check you're within boundaries and throw an exception if it's out of bounds.

Herein lies the issue: "You can't throw exceptions in this kind of software". True. So how do you prove it WONT go out of bounds at compile time, if the input isn't trusted? Rustacians get picked on a lot for spending more time on type-theory than actually writing working code, but from my perspective it looks worse in Ada, obsessing over proving something in a complete vacuum that can't possibly account for all possible invariants in the real world.

I don't see how this is any different than countries putting significant portions of their gold & currency reserves in the NY Federal Reserve Bank. If for some reason the U.S. just decided to declare "Your monies are all mine now" the effects would be equally if not more devastating than a data breach.

I understand data sovereignty in the case where a foreign entity might cut off access to your data, but this paranoia that storing info under your bed is the safest bet is straight up false. We have post-quantum encryption widely available already. If your fear is that a foreign entity will access your data, you're technologically illiterate.

Obviously no person in a lawmaking position will ever have the patience or foresight to learn about this, but the fact they won't even try is all the more infuriating.

Given the topic of the thread is DARPA it's unlikely they're going to benefit from the type of overlap C++ and C# have in game engines or DBMSes.

Every time this subject comes up there is always a "well MY C code is safe so Rust is a stupid language! You're just using the <language wrong/wrong tools>".

I find it funny how much folks foam at the mouth about using X or Y wrong in a language that specifically chose to be flexible to fit into any possible combinations of toolsets and now you're telling people they need to use YOUR tools.

Meanwhile Rust has solved this problem by having 1 compiler, 1 package manager, 1 formatter, 1 way to run tests, etc. etc. C/C++ will never have this because of how fragmented the ecosystem is. That's the price paid over years of committee decisions which prioritized industry customization & backwards compatibility above all else. You cannot have your cake and eat it too.

C++ and C# share a letter only. They operate in entirely different domains. You can certainly try to write PLC logic or a an IMU Sensor in C#, but that's probably not going to be a fun task.

Something somewhere needs to change because the status quo just isn't working. Yes, we can cheer on the benefit of OIDC tokens and zero-trust solutions in CI pipelines on HN all we want, but the fact is there's a significant number of library developers out there with millions of package downloads per week that will refuse to do anything about security until they're compromised or npm blocks them from publishing until they do.

And then there's other non-sensical proposals like spelunking deep into projects some which could be over a decade old and just rip out all the dependencies until there's nothing but a standard library is left. Look, I'm all for a better std lib, I think reducing the number of dependencies we have is good. But just saying "you should reduce dependencies" will do nothing concrete to fix the problem which already exists, because it's much easier said than done.

So either tens of thousands or hundreds of thousands of developers stop using npm, and everyone refactors their projects to add more code and strip dependencies, or npm starts enforcing things like 2FA and OIDC for package developers with over X number of weekly downloads, and blocks publishing for those that don't follow the new security rules. I think it's clear which solution is more practical to implement. The only other option is for npm to completely lose its reputation and then we wind up with XKCD 927 again.

I switch between gpt-oss:20b/qwen3:30b. Good for green fielding projects, setting up bash scripts, simple CRUD apis using express, and the occasional error in a React or Vue app.

That's really underselling it. Gaokao determines where you can live, where you can work, who your friends are, occasionally how much your family values you. They shut down airspace and conduct military/police patrols during examinations to sniff out cheaters. It's only the very wealthy who can just uproot their lives and send their kids to an Ivy/Stanford/Oxbridge/MIT and just skip the whole thing.

Responding to the OC, this is a downright awful solution to the current education problem in the U.S.

https://www.hup.harvard.edu/file/feeds/PDF/9780674295391_sam...

I regularly use local LLMs at work (full stack dev) due to restrictions and occasionally I get some results comparable to gpt-5 or opus 4

Then why does AWS charge less for the same compute workloads on ARM?

anything involving the medical industry (HIPAA laws), national security (FedRAMP is such a pita to get that some military contractors are bypassing it to get quicker access to cloud tools) etc.

Besides that, we are moving towards an era where we won't need to pay providers a subscription every month to use these models. I can't say for certain whether or not the GPUs that run them will get cheaper, but the option to run your own model is game changing for more than you can possibly imagine.