Where is the fork of Rust that accepts AI contributions? We need that desperately.
The Rust language does not currently have an LLM policy, but the one under discussion is not a total ban.
Announcing Rust 1.96
31–39 of 39 posts
Re: Announcing Rust 1.96
#32Earlier quoted context omitted.
That would be a reasonable worry, except that this specific issue has been discussed for like, a decade. It’s the only beef people have. It’s unlikely that they’ll find something else any time soon.
Talking about this specifically, yes it's difficult to think of a reason to change ranges in the future. But bringing my post to a more general stance, I'm of the opinion that Rust is fixated a bit too much on the goal of having a minimal core and leaving the ecosystem to find its own ways forward. Maybe it wouldn't hurt that much if the language, with its current age, started opening up to providing more of the stuf…
Async engines are one of the worst things you could have chosen as an example. They are wide and varied, with a ton of different tradeoffs for different scenarios. Ones for high performance networking are also complex, requiring tremendous engineering effort, and are massive. Putting something in the stdlib doesn’t magically make something better maintained.
Interfaces also do not magically become good or useful. There has been suggestions around some async traits, but no suitable one has actually been found yet. Yes, it has been a very long time, but that’s just how it goes sometimes.
Re: Announcing Rust 1.96
#33Earlier quoted context omitted.
I don't follow Rust closely, but I somehow love that they just did it. I like C++, but it would be much less confusing if the committee dared to change the language or std from time to time. Instead, they only ever extend (with super rare outliers).
For better or worse, that is one reason why many of us still reach out to C++. Especially because ISO languages always have to care about multiple implementations, C++ isn't alone in this.
Note that the thing Rust is doing here doesn't break backwards compatibility, because of the edition mechanism. C++ doesn't have that (I don't know if they've considered adding it), so they can't do anything about language footguns without compatibility breaks.
Rust idioms do of course change over time, such that if you come back to the language after a while you'll have some catching up to do, but that's just as true of C++.
Re: Announcing Rust 1.96
#34Earlier quoted context omitted.
For better or worse, that is one reason why many of us still reach out to C++. Especially because ISO languages always have to care about multiple implementations, C++ isn't alone in this.
Note that the thing Rust is doing here doesn't break backwards compatibility, because of the edition mechanism. C++ doesn't have that (I don't know if they've considered adding it), so they can't do anything about language footguns without compatibility breaks. Rust idioms do of course change over time, such that if you come back to the language after a while you'll have some catching up to do, but that's just as tru…
> (I don't know if they've considered adding it)
The paper you want to look up is “epochs” (the OG name for editions) but there were questions that never got resolved, and so the proposals are dead for now at least.
Re: Announcing Rust 1.96
#35Earlier quoted context omitted.
Or just make it more difficult to squat obvious namespaces, and add an identity management system (like PGP Web of Trust, but simpler) so you can limit yourself to trusted packages, e.g. packages vouched by your preferred set of root signers who publish compilations of trusted publisher keys. Expecting a kitchen sink approach for a low-level language can't work out. In low level systems languages your algorithms and…
> so you can limit yourself to trusted packages, e.g. packages vouched by your preferred set of root signers who publish compilations of trusted publisher keys. This is really not good enough. The real gigantic problem with supply chain risk is not that you get tricked to use a package by bad actor, it is that if everyone using gazillion packages by known good authors, that makes all those known good authors with upl…
The C++ std lib is no longer terrible. It is really at a usable level these days. Not fun, but totally bearable. The motivation for C++ has never been the quality of the language or the std lib anyways, so it can happily chug along in many places (including the browser I am typing this on).
I disagree about merging existing "done" libraries into a mega library. That can work to some extent, but that approach will not produce something lasting (in the sense that it will remain without the need for changes for a long time). The way to achieve a lasting mega library is by putting all the pieces you need, and constantly working to increase the consistency between them. Somewhat like turning a long winded rambling into a much denser article.
Going from a set of good and working libraries to a large CONSISTENT library would be substantially laborious. Hence the need for someone with deep pockets to take it on. (There are other ways for that to happen but those are rarer).
Re: Announcing Rust 1.96
#36Earlier quoted context omitted.
C++ (the language) and its extreme complexities (each perhaps added for a good reason at the time, and then held together with backward compatibility as glue) reduced itself to gcc and clang. Not the std lib. The std lib is, de facto, removing some of the complexity. Recent C++, together with a couple of major libraries, and with a good style guide and a matching lint (that removes / restricts many footguns) is far b…
> Recent C++, together with a couple of major libraries, and with a good style guide and a matching lint (that removes / restricts many footguns) is far better than it was, 15-20 years ago. While it is not exactly cool, it can be totally bearable. Which is the main reason why despite its warts, C++ is my go to systems language, when I need to do something outside Java, C#, node. It is anyway for "unsafe stuff" for th…
Honestly, at fundamental level, it is less of that need being dependent on third parties, and more of not having at least ONE set of consistent libraries (or one big library). To me the real value add of golang's std lib is not that it is developed by the language authored (that is maybe the third or fourth key point). The first one is the existence of one set (or 1.5, heh, if you consider golang.org/x slightly different) of libraries that are polished and hammered to be consistent together (primarily by spending an enormous effort on simplicity, but also on repeated polishes prior to the first notable public release and some thenafter). This is at the core of what I think rust needs right now to break through and penetrate into real C++ and golang circles.
Re: Announcing Rust 1.96
#37Earlier quoted context omitted.
For better or worse, that is one reason why many of us still reach out to C++. Especially because ISO languages always have to care about multiple implementations, C++ isn't alone in this.
Note that the thing Rust is doing here doesn't break backwards compatibility, because of the edition mechanism. C++ doesn't have that (I don't know if they've considered adding it), so they can't do anything about language footguns without compatibility breaks. Rust idioms do of course change over time, such that if you come back to the language after a while you'll have some catching up to do, but that's just as tru…
Editions for the time being don't cover all language evolution scenarios, e.g. breaking changes on the standard library, and having incompatible crates on the same build talking to each other.
Re: Announcing Rust 1.96
#38Earlier quoted context omitted.
Note that the thing Rust is doing here doesn't break backwards compatibility, because of the edition mechanism. C++ doesn't have that (I don't know if they've considered adding it), so they can't do anything about language footguns without compatibility breaks. Rust idioms do of course change over time, such that if you come back to the language after a while you'll have some catching up to do, but that's just as tru…
Editions for the time being don't cover all language evolution scenarios, e.g. breaking changes on the standard library, and having incompatible crates on the same build talking to each other.
Is anybody contemplating nontrivial breaking changes to the standard library? When env::set_var and env::remove_var were marked unsafe, that was done across an edition boundary even though it's unsound to leave them as-is in older editions.
Do you have a particular scenario in mind for incompatible crates? This doesn't seem like a language evolution problem.
Re: Announcing Rust 1.96
#39Earlier quoted context omitted.
That would be a reasonable worry, except that this specific issue has been discussed for like, a decade. It’s the only beef people have. It’s unlikely that they’ll find something else any time soon.
Talking about this specifically, yes it's difficult to think of a reason to change ranges in the future. But bringing my post to a more general stance, I'm of the opinion that Rust is fixated a bit too much on the goal of having a minimal core and leaving the ecosystem to find its own ways forward. Maybe it wouldn't hurt that much if the language, with its current age, started opening up to providing more of the stuf…
> but not even compromising on an async engine
FWIW, Tokio's API is not the right one for io_uring, buffer pools for reads changes everything. There'll be yet another huge ecosystem churn. I'm personally hoping for it to happen sooner rather than later.