This is probably going to sound generic / repetitive, but my biggest complaint about Rust is the package management situation, which is entirely the result of the developer mindset. I love the ergonomics on the rust side (the functional approach to data types is beautiful), but I’m working on two projects side by side, one in rust and one in go at the moment. The dependency trees are entirely different beasts, with most of the stuff on the go project covered by the stdlib whereas I think the rust project is over 400 despite asking for just rusqlite (sqlite), clap (cli), ratatui (tui), and tauri (gui), the last of which is by far the worst offender but even without it, it’s still close on 100 which is crazy. If there were (and maybe there are, I just haven’t found them) decently maintained alternatives to the rust crates that actually have a sane dependency approach, I’d feel much better. I’m just trying to not shai hulud my system, and the rust-web people seem to want to turn cargo into npm in that regard.
Note that many Rust libraries consist of multiple crates, which all end up in the dependency graph. This makes the number of dependencies seem higher than it actually is: the separate crates have the same maintainers and are often part of the same upstream git repo.
I agree with the general sentiment though. Rust also has a lot of crates that are stuck semi-unmaintained at some 0.x version, often with no better alternative.
Unfortunately the 0.x version has pervaded because of community cargo culting claiming that versioning is easier with 0.x than with major version numbers > 0. Personally I find that hard to believe, especially given packages like Tokio and anyhow (still at v1) make it work and there’s others that are >v1.
That is to say 0.x doesn’t necessarily mean unmaintained, it can also mean “I don’t want to have to think about how to version APIs / make guarantees about APIs). Eg reqwest is very widely used and actively maintained yet is still at v0.13.
> claiming that versioning is easier with 0.x than with major version numbers > 0
I think it's less that versioning is claimed to be easier with 0.x versions, and more that some people have got into their heads that 1.0 signals either "permanently stable" or "no new versions for several years" and they don't want to commit to that yet.
I do wish more crates would 1.0 (and then 2.0, etc).
There is good reasons to break out projects into multiple crates. It makes reusing functionality elsewhere easier. It makes it easier to reason about behavior. It makes it easier for LLMs to understand (either working within the crate or consuming as an api surface.) So you end up with projects that have multiple crates inside the same workspace and it really blows up dependency count.
The other very important reason for splitting into crates is compile times. Crates are the "compilation unit" and you often get more build paralellism with more crates.
To highlight the problem for Python: Python's standard library has getopt, optparse, and now argparse. I don't think they set out to offer 3 argument parsing libs, one of which is marked superseded, but here we are.
At least in the case of sqlite, rusqlite pulled in 5 or so in total whereas Go had a single library that was a thin wrapper around sqlite, and integrated into the stdlib interface. Many fewer deps
Edit: counts are fair, that’s still hundreds unaccounted
Package management is the bane of nearly every language/technology
Nobody has "solved" it, and I don't think that there will ever be one (never say never, though, right?)
For Go we rely on developers of libraries to adhere to the semver versioning scheme accurately, and we cannot "pin" versions (a personal bugbear of mine)
There is a couple of workarounds - using SHAs not unlike the git commit hash to provide a pseudo version, and, vendoring (which is a cache of known dependencies - which brings with it cache management problems)
I had the misfortune of having to use Python with a virtual env on the weekend - it did not end well, and reminded me why I migrated away from Python.
Look at
Perl (cpan)
Java (maven, gradle)
Ruby (gems)
Go (dep, glide, vgo, modules)
Rust (cargo)
Node (npm, yarn, etc)
OSes too
Redhat (yum, rpm, etc)
Debian (apt)
Ubuntu (snap - god why????)
Actually with Go modules you are always pinning dependencies. What’s in your go.mod is what is used. If your go.mod needs to be updated because a dependency wants to bring in a newer version of a transient dependency, the go.mod has to be modified (by the go command, not by you)
There is something you can do to stop it actually. You can use a replace directive, specifying that a module is replaced by itself at a fixed version. See e.g. https://stackoverflow.com/a/77412524/814422
It is worth noting though that, even without such pinning, `go mod tidy` does not update versions willy-nilly. [edit: the following is inaccurate, see grandchild comment] It only syncs go.mod with what is already being used by the build process. In other words, if you see `go mod tidy` change a version, it means that you haven't tidied the file since making other changes to it, and the listing in go.mod was stale with respect to the resolved set of transitive dependencies actually being used.
Indeed, I ran two tests (missing indirect dependency, stale indirect dependency version) and it refused to compile both. Either what I said was never true, or it was only true for earlier versions of the `go` command. Nevertheless, adjusted accordingly, I believe the following statement is true: `go mod tidy` doesn't change versions in go.mod unless it needs to, to satisfy the other dependencies listed in go.mod, or to fill in a missing dependency for an import in code. It would be nice if there were a flag to turn off the latter behavior, though.
Pinning to me means there is a file with all the versions as they will be used. I don’t see how “go mod tidy” modifying it is different from “bundle install” modifying it.
> I had the misfortune of having to use Python with a virtual env on the weekend - it did not end well, and reminded me why I migrated away from Python.
I see this sentiment a lot, and it doesn't match my experience at all.
In my decade-old bubble of using Python professionally, I've never had an issue with virtualenvs. The few issues I might've had with dependency resolution must be so far in the past that I don't remember. But that's not strictly about virtualenvs. Likewise, pip could be clunky, but we don't have to deal with it anymore.
My niche is mostly backend. Other Python niches must be considerably worse in this regard.
I used Python for a decade (professionally), gave up on it once I started using Go (professionally) in earnest - about 8 or 9 years ago.
I never liked virtual envs, having to remember where they were, what their names were, and what was installed into each one was a pain point for me.
This weekend I was trying to learn some AWS stuffs, and I cloned the official repo of example code which was Python. I followed the directions exactly and ... boom Python versioning issues... inside the freaking venv
Who needs that?
Why do I need to spend the better part of a couple of hours debugging a versioning problem? (FTR The problem turned out to be the repo was hardcoded to 3.8 and my local Python was 3.9.. or something along those lines - you are welcome to correct me, but that's what I remember of a painful waste of my time)
With Go I have backward compatibility guarantees - usually (there have been instances in the past where the backward guarantee have been broken AND the build process got broken hard for modules, with the claim that it was external and therefore not subject to the same guarantees)
> I see this sentiment a lot, and it doesn't match my experience at all.
My old HCI professor used to tell me - if users are complaining (or producing workarounds like post-it notes on their monitors) - regardless of how clean or elegant you think the system is - it's not.
You're saying you see people complain about it a lot - therefore it's a genuine problem.
> having to remember where they were, what their names were, and what was installed into each one was a pain point for me.
It's at the project root, it's named 'venv', and its contents are described by requirements.txt.
> You're saying you see people complain about it a lot - therefore it's a genuine problem.
Debatable as a principle, but applicable enough here I suppose. Still, I'm not saying the problems aren't real, but what I (and probably most of us virtualenv users) are saying is that there's a pretty broad swathe of projects where you don't encounter them. It's just fine. You install your packages and use your packages and that's the whole story.
I guess if you have a hard dependency on a particular version of python, it's going to be harder, but... why? That's already niche in my book. If you're saying the AWS repo was pinned to a particular version of python, I'm going to blame that on Amazon frankly. That's definitely bizarre.
Edit: Were you looking at this? https://github.com/boto/boto3 Definitely more complicated than a typical greenfield virtualenv-able project, with some python version restrictions.
> what I (and probably most of us virtualenv users) are saying is that there's a pretty broad swathe of projects where you don't encounter them.
Zero. The required number of problems needs to be zero - hence my OP
> I guess if you have a hard dependency on a particular version of python, it's going to be harder, but... why?
The bigger question is - why doesn't 3.9 compile and run 3.8
Further, in what world is targeting a specific runtime version in an enterprise production environment "niche"?
When you are deploying to managed corporate infrastructure, AWS Lambda runtimes, or strict Docker base images, you don't just get to loosely target "whatever Python version happens to be on the developer's laptop." You target an exact runtime version (e.g., Python 3.10) because language syntax, standard library features, and performance characteristics change between minor releases.
The fact that Python forces the developer to manually manage isolated directory symlinks (venvs) just to prevent local environment contamination — and that minor runtime mismatches can completely derail a standard onboarding experience — is a structural UX failure.
> Zero. The required number of problems needs to be zero - hence my OP
This is unrealistic. You seem to have moved to Go as an alternative, but I know because I've seen the complaints that Go doesn't satisfy that standard either.
I was trying to be sympathetic and acknowledge virtualenv's potential flaws, actually, even though I haven't personally encountered them, but I guess that was a waste of time.
> This is unrealistic. You seem to have moved to Go as an alternative, but I know because I've seen the complaints that Go doesn't satisfy that standard either.
It's a dig - you completely ignore the valid complaints about Python to instead focus on what you think will provoke me.
The problem (for you) was, from the very start, I bought up the pain points with Go.
> Still, I'm not saying the problems aren't real, ...
> I'm going to blame that on Amazon frankly. That's definitely bizarre.
I'll grant I lost track of the context that you were trying to raise the possibility of some grand encompassing solution to all programming language package management. All I wanted was to reinforce the idea that virtualenv is Often Just Fine in practice, at least if used in sensible ways.
No - go.sum alerts you to the change - it doesn't prevent it.
replace directives are ok, but you need to look at why workspaces were invented to get an idea of their shortcomings (hint: people used to have a replace directive locally that they would accidentally push and that would break other peoples builds)
It did and didn't. Nix tools for building language-specific packages almost always wrap the language build tool/package manager. This can be easy or hard, depending on how onerous the build tool is for vendoring libraries.
What Nix and build tools need to agree on is a specification or protocol for "building a software dependency tree". Like, I should be able to say 'builder = cargo' in a Nix derivation and Cargo should be able to pick up everything it needs from the build environment. Alas, there is simply far too much tied up in nixpkg's stdenv for this to be viable, so we have magic stdenv builder behavior via hooks when a build tool is included in nativeBuildInputs.
I think one of the key problems too is that a system level dependency is managed by people dedicated to ensuring the chaotic nature of the package they are responsible for conforms to the way the OS they are maintaining for has proscribed.
There's no real way to do that at a language level - we cannot have "Go has determined the package you are trying to fix has not met the versioning requirements proscribed so you cannot submit the patch to fix it"
What language dependencies do is what OSes would think of as "unofficial versioning" that is, an OS will let you install and run an unofficial version of some lib (we've all been there, right, multiple versions of some core library because one doesn't work with whatever you are trying to install), but they will not manage it at all.
That's an interesting viewpoint, but one I've noticed is less prevalent in other languages.
The c# guys at microsoft created an enormous stdlib, and the overwhelming majority of it is pretty good. The outliers being of course older stuff they've never really had time to upgrade. And they don't seem to be afraid to deprecate stuff, every major version brings a couple of minor breaking changes. But it all seems to work out just fine somehow
C# massive standard library and first party libraries means much, much fewer external dependencies and these libraries are managed by a team of paid, professional engineers.
I’d argue that this is wrong. Having a conservative standard library that aims to contain most things most people need is preferable to third party libraries in 90%. For the 10% that isn’t covered to your liking by the standard library you can turn to third parties. You get both a practical standard library and third party options.
I did a lot of cryptography over the past couple of years. Go has that in the standard library. For the last decade and a half cryptography is something that every developer has to deal with at some point, and it NOT being the awful pain that it is in just about any other language, is a good thing. Sure, it does not contain every algorithm and mechanism in the world, but it contains everything you need for 90% of cases. That means that most of the time you don’t have to do the extra work of ensuring you have an out if the library you depend on should go away/bad, bugs will be fixed, people speak a common language and you don’t have to do twice the work in terms of risk assessment.
People keep forgetting that you have to evaluate these things in the real world. In practical real-world situations. The real world is not about what works in theory but what actually provides value for actual people working on actual projects.
The stdlib isn't necessarily better, but it's always there. To use Python as an example, I tend to prefer requests to urllib2, as do most programmers. But I've absolutely been in scenarios where all I could get was the stdlib, and having urllib2 saved my ass. I think it's extremely important for the stdlib to be batteries included, even if they aren't the best versions of those batteries on the market.
The problem is that trust shouldn't be so binary. We should have ways to increase trust without needing to resort to the standard library. There was an effort to do this at some point in rust but the idea was sadly not well received. Maybe it'll end up reviving itself with modern supply chain concerns.
The idea is that there could form some groups of well maintained crates that only depend on each other and have a similar amount of oversight. This actually naturally happens in c++ because grabbing dependencies is so painful, but it makes dependencies more trustworthy. For instance boost, absl, folly, etc.
I've harped on this for years, but few devs seem to grasp the concept that less dependencies is better than more. Especially library authors.
It's only now that the supply chain problems with npm are becoming beyond obvious that we are seeing devs come around to this notion (leftpad should have been the canary in the coal mine).
The javascript ecosystem has corrupted far too many other programming ecosystems. The notion of "just make a small package like is-even" is really the core of the problem. But also people making libraries often have the wrong mentality about that process. They think of it like they are making an application (So why not just pull in a bunch of random deps). Every dependency a library brings in should have a serious conversation and analysis on "how much work would it be to just do this functionality here". And if it's not that much, then preference should be to duplicate, not depend.
A lot of libraries should have been gists, blog posts, or stack-overflow answers. When I see a library imports a dependency of a few function related to its domain, I can’t help but wonder why they don’t want to take responsibility for that small snippet of code.
If you look at the number of authors vs the number of dependencies the gap narrows but doesn't disappear. Many of the most commonly used crates are written by members of the rust foundation amd are used in the tools themselves. But it is always a concern. I'm looking forward to the upcoming option to forbid versions newer than N days at the project level. But just manually only y updating versions when you need a new feature or there is a cve works pretty well.
Why is it worse to import a number of other packages that provide exactly the functionality you need, than to have a large standard library that provides some but not all of the functionality you need, requiring you to still use some large dependencies?
Go's stdlib has none of the things GP listed. No sqlite3, no ratatui, no cli (though there is `flag` if it's enough for you), and no tauri equivalent in its stdlib. Those would be go-sqlite3, bubbletea, cli or cobra, and wails.
Charitably, I think OP meant to say that in the rust project only four dependencies were added and that caused 400 transitive dependencies to be pulled. Adding the four Go equivalent will still result in 10x less packages being pulled.
It's a culture problem, Go authors prefer solutions that are self contained, rust authors embrace the culture that gave us left-pad.
But, at least in GP's case, it's not a stdlib problem. Not one solved by Go, anyway.
> So far, Mythos Preview has found what it estimates are 6,202 high- or critical-severity vulnerabilities in these projects (out of 23,019 in total, including those it estimates as medium- or low-severity).
> 1,752 of those high- or critical-rated vulnerabilities have now been carefully assessed by one of six independent security research firms, or in a small number of cases by ourselves. Of these, 90.6% (1,587) have proved to be valid true positives, and 62.4% (1,094) were confirmed as either high- or critical-severity. That means that even if Mythos Preview finds no further vulnerabilities, at our current post-triage true-positive rates, it’s on track to have surfaced nearly 3,900 high- or critical-severity vulnerabilities in open-source code
I think it's more that the requested information is prominently featured in the article, and indeed is the content of the only graphic in the article below the intro banner.
> Not even half-way through this #curl release cycle we are already at 11 confirmed vulnerabilities - and there are three left in the queue to assess and new reports keep arriving at a pace of more than one/day.
> 11 CVEs announced in a single release is our record from 2016 after the first-ever security audit (by Cure 53).
> This is the most intense period in #curl that I can remember ever been through.
He’s talking about AI scanning tools collectively, not specifically Mythos.
If you read his own top comment on that LinkedIn post he clarifies:
“The simple reason is: the (AI powered) tools are this good now. And people use these tools against curl source code.They find lots of new problems no one detected before. And none of these new ones used Mythos. Focusing on Mythos is a distraction - there are plenty of good models, and people who can figure out how to get those models and tools to find things.”
Wait, 11 vulnerabilities were discovered entirely in the timeframe after Mythos found 1? That seems like it would effectively debunk the theory that curl was so uniquely hardened that only 1 vulnerability even existed for Mythos to find, which I read numerous times back on the HN thread for the curl/Mythos blog post.
As one of those commenters on the previous post - yep, that theory appears to have been comprehensively trounced. Unless anything comes to light that mythos was applied poorly to curl, the evidence suggests that it’s not uniquely effective vs other AI-assisted approaches. I’ll be interested to see what’s reported in the next curl release.
I believe, but could be wrong, is that the big change is the time frame for index and managed funds buy in. It used to be a year, but it's much shorter now, like 2 weeks. Which means as long as they can maintain a high market cap relative to their exchange for that time period they will be stabilized by institutional funds and basically crowd sourcing any losses to the public and massively cashing out the internal pre-ipo investors.
At least that's my understanding of the current market dynamics regarding IPOS, if I'm wrong that would be great, and if someone else would explain it even better.
The CFO doesn't even report to Sam Altman directly. I would not assume that the decision is up to her in any meaningful way. I predicted a while ago and still stand by an 80% chance that their S1 is disastrous on the scale of WeWork; so, so much of what people think they know about OpenAI's finances is based on snippets and rumors rather than firm audited statements.
They’ll be using every trick in the book to massage the numbers as much as possible, but even so it’s hard to see how an S1 for OpenAI or Anthropic doesn’t look pretty terrible
People usually use the term for poorer countries, as opposed to the rich ones. Originally third world meant those not aligned with the USSR or NATO, I believe.
I get the meaning of "third world" but the USSR hasn't existed for decades, is China the modern equivalent? And it wasn't made clear why a neutral country like Switzerland would be expected to be highly corrupt while Russia would be low in corruption. Or indeed why Switzerland would be seen as a country in the process of becoming financially rich.
> How does a company even consider this while the CFO is privately saying the books / revenue accounting are not ready for public scrutiny?
Perhaps they will just tell a lot of lies.
In the past people would generally avoid this when it came to stock market filings for fear of legal consequences, but the OpenAI C-Suite is already at least +$26 million to Trump and has plenty more to send his way if that doesn't cover it.
Crime is legal in 2026 (if you can afford the kickback fees).
Crime is legal, but investors can and will dissect your 10-Q/10-K statements. Anyway, I think that the Administration covering their asses in the face of doubtful numbers will shake investor confidence in the tech field. In fact, most investors will think one of these two things:
1. "Look, even OpenAI, which is the face of the LLM tech with ChatGPT, needs assistance from POTUS to stay afloat, the tech is not profitable"
2. "Crap, all this circular economy going on with Nvidia/OpenAI/... is bogus after all if even OpenAI needs the White house support to survive. There is not enough demand".
Regardless of the specifics, if this sentiment spread enough (and it doesn't have to be the majority of investors) everyone, regardless of their beliefs, will start selling to avoid being the last one standing when the music stops.
I'm guessing they had a significant revenue spike from gpt 5.4 and gpt 5.5 being so good at coding, and hiccups at anthropic making it easier for programmers to try the models.
Can't they just tell GPT-5.5 to fix their books, make no mistakes? Are the accountants also not replaceable by AI when doctors, lawyers and engineers are?
Current investors know the hype is sufficient to not worry about all those niggling financial details and want liquidity now -- retail will buy them out.
Built on meaning the technology is using Git under the hood, not that it is developed using git.
Edit:
Breaking down the “word salad”:
> Radicle is a peer-to-peer code collaboration platform (“forge”) built on Git.
Peer-to-peer: it functions with individual nodes on the network spreading state for tracking it without relying on a single entity or centralised service.
Code collaboration platform (forge): you use it not just to store code but provides a way to keep track of “patches” (their term for PRs) and issues, amongst other things, to enable multiple people to collaborate on a code base
Built on git: the technology runs on top of git insofar as not only is the VCS just git, but the issues, patches, etc are stored in git. So the project isn’t merely developed using git, but when running the tool yourself it’s still backing everything under git.
Since the exploit can be mitigated by simply blacklisting the AF_ALG module, why didn’t they release an advisory to disable the problematic module (which AFAIU is hardly used), and then only later, say after a week, release the patch for it? At least then you would have the immediate ability for a mitigation without giving away exactly how to exploit the bug.
reply