That's great news, I'll have to try to replace pyenv (again).

I am not a huge fan of Go, but if all the world's "serious" Python became Go, the average code quality would skyrocket, so I think I can agree to this proposal.

Go performance is terrible for numeric stuff though, no SIMD support.

I love Rust and C, I write quite a bit of both. I am an ML engineer by trade.

To say most ML people are using Rust and C couldn’t be further from the truth

> It, too, would benefit from becoming Rust.

Yet it was created for Python. Someone took that effort and did it. No one took that effort in Rust. End of the story of crab's superiority.

Python community is constantly creating new, great, highly usable packages that become de facto industry standards, and maintain old ones for years, creating tutorials, trainings and docs. Commercial vendors ship Python APIs to their proprietary solutions. Whereas Rust community is going through forums and social media telling them that they should use Rust instead, or that they "cheated" because those libraries are really C/C++ libraries (and BTW those should be done in Rust as well, because safety).

> Dunno, almost all of the people I know anywhere in the ML space are on the C and Rust end of the spectrum.

I wish this were broadly true.

But there's too much legacy Python sunk cost for most people though. Just so much inertia behind Python for people to abandon it and try to rebuild an extensive history of ML tooling.

I think ML will fade away from Python eventually but right now it's still everywhere.

Okay. Humor me. I want to write a transformer-based classifier for a project. I am accustomed to the pytorch and tensorflow libraries. What is the equivalent using C?

TensorFlow is a C++ library with a python wrapping, yet nobody (obviously exaggeration) actually uses tensorflow (or torch) in C++ for ML R&D.

It's like people just don't get it. The ML ecosystem in python didn't just spring from the ether. People wanted to interface in python badly, that's why you have all these libraries with substantial code in another language yet development didn't just shift to that language.

If python was fast enough, most would be fine to ditch the C++ backends and have everything in python, but the reverse isn't true. The C++ interface exists, and no-one is using it.

> I am always flabbergasted when people make such statement

Sit down, have a coffee, re-read your whole comments, create bullet points for your case, and try to have an *objective* look at your arguments.

- Your are frustrated with your use case, seemingly to the point where you don't care about reasonable arguments but just want to lash out at something.

- By your own description, you have a specific use case, in a specific field, in a narrower sub field.

- You are not primarily a Python developer, and use it every 3 months when you have to.

Your experience, in your field, on your project, does not make you a poster child of what everyday Python is like. Sorry for the news.

Now I get that frustration of "I just want things done and not care about that whole ecosystem", but the reality is, that's not a Python thing, it's a "that's not my preferred stack thing".

I have that same feeling whenever I need to get things done in a stack I don't know, and get stuck by something <insert preferred stack> does.

I used Rust the other day and ended up in a case where I needed to implement a trait I do not own. Well that ended up not being possible. That pissed me off for a time, that *really* made the most sense for my use case. Yet... I'm not going to complain that Rust is unusable because of "trait ownership hell" on the internet.

If we let the frustration aside for a minute:

Your use case, as a fact, is very contrived.

One does not stumble into projects that need to work with different, incompatible, similarly named, versions of a same library, every day.

As I mentioned, when that need arises, library maintainers usually just create a new package, with a different name.

That is what have been done for 99.99% of package managers ever in existence, be it system package managers, or language package managers.

And the reason for it is really just common sense:

- It does not happen very often

- Whenever that happens, the solution of providing a new package is the simplest and most well established

- The pattern works, and has been used since 30 years

- It is unambiguous

Note that Rust does _not_ magically solve that problem either, as there is no one size fits all solution to this problem. The best Rust can do, is:

- In the subset use case of this problem where said dependency is solely accessed from the inside of another dependency

- And said library symbols need not be externally accessible

- And said library data structures need not be shared

- Then Rust can build the outer most dependency against a specific version of said inner dependency.

Yes, Rust can do this. I know Ruby cannot, and I believe Python may not either, but I am less sure about it because I’m less good with Python’s semantics here, but I’d believe your parent.

> That's just like, your opinion, man.

I would love to know how many younger readers recognize this classic movie reference.

i mean, unless you have some absolute divine truths, that's kind of the best i have :shrug

my thesis is that negative externalities of build systems are important and i don't know how to convince of importance of externalities someone whose value system is built specifically on ignoring externalities and only factoring in immediate convenience...

that's two different languages, they don't have have a standardised build system across them

They are different:

    "0": ">=0.0.0, <1.0.0"
    "0.9": ">=0.9.0, <1.0.0"
    "0.9.3": ">=0.9.3, <1.0.0"

The reason for this is that unless otherwise specified, the ^ operator is used, so "0.9" is actually "^0.9", which then gets translated into the kind of range specifier I showed above.

There are other operators you can use, these are the common ones:

    (default) ^ Semver compatible, as described above
    >= Inclusive lower bound only
    < Exclusive upper bound only
    = Exact bound

For this reason, if you are writing a library, you should in almost all cases stick to regular semver-compatible dependency specifications.

For binaries, it is more common to want exact control over versions and you don't have downstream consumers for whom your exact constraints would be a nightmare.

Note that in the output, there is rand 0.9.0, and two instances of rand_core 0.9.3. You may have thought it selected two versions because you missed the _core there.

> So there's no difference at all between "0", "0.9" and "0.9.3" in cargo.toml

No, there is a difference, in particular, they all specify different minimum bounds.

The trick is that these are using the ^ operator to match, which means that the version "0.9.3" will satisfy all of those constraints, and so Cargo will select 0.9.3 (the latest version at the time I write this comment) as the one version to satisfy all of them.

Cargo will only select multiple versions when it's not compatible, that is, if you had something like "1.0.0" and "0.9.0".

> Surely there's some way to actually require an exact version?

Yes, you'd have to use `=`, like `=0.9.3`. This is heavily discouraged because it would lead to a proliferation of duplication in dependency versions, which aren't necessarily unless you are trying to avoid some sort of specific bugfix. This is sometimes done in applications, but basically should never be done in libraries.

Within a crate graph, for any given major version of a crate (eg. D v1) only a single minor version can exist. So if B depends on D v1.x, and C depends on D v2.x, then two versions of D will exist. If B depends on Dv1.2 and C depends on Dv1.3, then only Dv1.3 will exist.

I'm over-simplifying a few things here:

1. Semver has special treatment of 0.x versions. For these crates the minor version depends like the major version and the patch version behaves like the minor version. So technically you could have v0.1 and v0.2 of a crate in the same crate graph.

2. I'm assuming all dependencies are specified "the default way", ie. as just a number. When a dependency looks like "1.3", cargo actually treats this as "^1.3", ie. the version must be at least 1.3, but can be any semver compatible version (eg. 1.4). When you specify an exact dependency like "=1.3" instead, the rules above still apply (you still can't have 1.3 and 1.4 in the same crate graph) but cargo will error if no version can be found that satisfies all constraints, instead of just picking a version that's compatible with all dependents.

can does not mean must. Cargo attempts to unify (aka deduplicate) dependencies where possible, and in this case, it can find a singular version that satisfies the entire thing.

I think pretty clearly the source is also at least partially generated. None the less, just a README like that already sends a strong signal to stop looking and not trust anything written there.

`llm.rs` has many `impl LLM` blocks