If someone has antique computer that still works, that's great, but they shouldn't expect to have the latest software for it.
If they are not critical then well, why should other people care?
Also, Python packaging is pure hell.
Not just niche or antique!
IMO Rust should have a C backend, then the maintainers could drop it as a build dependency and not break existing platforms. Though I expect there to be political reasons for Rust’s conspicuous lack of a C backend.
I don't think there's any ideological opposition to having more back-ends. It's just a huge amount of work, and is lacking volunteers, especially for niche platforms.
For another, from personal experience, I can comment that compiling to C in such a way that doesn't leak abstractions left and right is quite challenging. It's pretty hard to produce memory-safe C, so it's a ton of work, and the payoff is pretty marginal, as the most important platforms already are supported by LLVM.
That's a lot of work you expect from people developing a language you don't even want to use.
This might prove right eventually - or might very well end up just like Java, for which similar claims were made. The smugness around Java was moderated a bit by the more corportey image of it, but the gist was quite similar nonetheless. Let's just say openly: the smugness is using up a lot of natural goodwill, and generating its own pushback. As there's no widely acknowledged "equal competitor" to Rust (why?), something feels "off" about the whole situation.
Edit: the maintainers didn't do semver right because the maintainers didn't do semver
Python is all over the place with versioning, making it hard to predict what scheme anyone is using. People either falsely assume semver or just don't do any version constraints, both leading to problems. Whats unfortunate, is the Poetry project is putting their head in the sand on this and not letting you patch transitive dependency versions [1]
Even if they did use semver, its still a contentious topic within projects using semver of what all is "included". Some people take an idealistic perspective of "if it might break me" but any change can break them [2], making it impractical. I've seen others take this as a sign that semver is impractical and shouldn't be used. I feel its a limited but useful communication tool; we have to accept imperfections in its use.
[0] https://cryptography.io/en/latest/api-stability.html#version...
> The new Rust code adds exactly 0 (zero) runtime packages to Cryptography. Rust, Cargo, pyo3, its dependencies, and setuptools_rust are build-time dependencies only.
Aren’t there tools available to build this on a supported platform and integrate the binaries in the systems in use? It is a bit convoluted, but seems like a solution at least for some (?) cases at additional cost.
[1]: https://github.com/pyca/cryptography/issues/5771#issuecommen...
Then there is the problem of there not being a standard dependency management system. Your `setup.py` can specify version constraints. You either over-constrain in there or have to add a whole separate process for locking your constraint.
- You could use `pip-compile` to get a platform-specific locking of constraints, requiring you to run this for every platform and python version you support. At least, since you duplicate `setup.py` into a `requirements.in`, you can override transitive dependencies.
- You could use `pipenv` and just capture what you happened to install, from constraints or directly, from a specific machine
- You could use Poetry which solves most of these problems except they've put their heads in the sand regarding how bad versioning is within the Python ecosystem and refuse to support overriding transitive dependencies despite being modeled off of Rust's Cargo which does support it despite the Rust ecosystem being good with versioning [1]
https://github.com/rust-fuzz/trophy-case
there are a few Rust ASN implementations. They've been caught running out of memory and having arithmetic overflows, but no segfaults or use-after-frees. Rust doesn't prevent all problems, but things that slip through tend to be less severe.
Having an authoritarian tone seems to be a prerequisite for being in the security industry. Unfortunately.
Especially in the security hardware world, getting customers to upgrade is like pulling teeth.
It's for this reason I've never liked the sprawling dependency-of-dependency mess that a lot of software projects seem to have.
I maintain the nodejs foundationdb libraries. Fdb doesn’t have a published wire protocol - bindings are expected to wrap a dynamically linked C library which contains the protocol implementation and net code. And that library is very “clever” - it leans heavily on codegen (via mono) and hand written asm to support a high performance actor model internally. The downstream effect is that FreeBSD support for database clients has only been added recently. There’s no native Apple M1 client support. There’s been issues with code signing in Java ... and so on. Generally you can only talk to a foundationdb server from an x86_64 client that runs Linux/macos/windows. Which is arbitrary and frustrating.
I hope wasm/wasi eventually becomes the standard for libraries like this. Then the binaries/packages we distribute can work in different languages, different OSes and different architectures without needing all this drama. Wasm bundles fit perfectly in pip/npm/etc. Write them in any language you want and they run fast & run everywhere.
On the other hand, you have you have an open source project that has to deal with the schedule/quality/cost trade off and people are expecting support for particular platforms without there being funding coming in to support those efforts. How much free work do they do so other people's company's continue to function?
I've started doing this with Nix for my own Rust projects, using the technique described here[1]. Planning on setting up a GitHub workflow to automatically open pull requests with bumped versions of nixpkgs/rust.
[1]: https://christine.website/blog/how-i-start-nix-2020-03-08
There is no clear cut answer in all of these situations and applying purity tests to semver instead just push another crowd of developers to abandon semver completely, making it hard to get any information communicated from your dependencies up to you.
Edit: @alex made a much better comment here:
https://github.com/pyca/cryptography/issues/5771#issuecommen...
One point that I didn't think of, but makes a ton of sense:
>There's no way to implement constant-time code in pure Python securely
Ultimately, projects upgrade/move. If you are dependent, that's something you need to deal with. If you're not ready to deal with it, then pin your dependencies until you are.
Many of the issues in the thread aren't necessarily problems with cryptography - for example pip not being able to deliver wheels to Alpine.
Any safety that can be provided by a library+Rust can be provided by another library+C++, with only a different apportionment of responsibility between library and language.
This isn't fully done in Alpine yet, and took a long time to do in Debian.
> MAJOR version when you make incompatible API changes,[0]
A build-time change isn't an API change, at least in my understanding.
If you're setting just constraints but not a specific version, then you're not pinning.
Sounds like a good argument to resurrect the LLVM C backend. As it stands, the Rust core team has no desire to implement a C backend, as it would be a ton of work for not much gain.