[hintoftime]

This might finally be the push for me to learn Rust. I'm primarily a Python developer working on Django, but I used to do embedded development in C, and Operating Systems with Remzi at UW Madison was my favorite class. It got me excited about CS. With Google and industry backing, it seems like Rust is here to stay.

[wongarsu]

It's worth mentioning that Rust-Python interoperability is already great, in both directions, thanks to pyo3

https://github.com/PyO3/pyo3

[MSFT_Edging]

Seconding this. I learned a little rust and really liked its philosophy. I was then working on a small project that needed to avoid the big data science python libraries because they're miserable in terms of portability to air-gapped networks.

We had re-implemented a few mathematical and curve finding functions and even with the newest python they were uncomfortably slow.

PyO3 made it so easy to implement a runtime switchable rust library exposed to python, it was almost unnerving. By writing those handful of functions in rust we got something like a 30x speedup.

Note this was a small project with limited funding for r&d so the level of effort for performance speedup was really nice.

[hintoftime]

Yeah, PyO3 is great. I've tried to play around with releasing the GIL from rust in Python 3.12. I would enjoy writing a WSGI/ASGI server with a Celery runtime at some point too. Or contribute to Granian.

https://github.com/emmett-framework/granian

[abdullahkhalids]

PyO3 is great. But it needs more and better documentation.

I recently did use it for a project, and it was quite a lot of time and pain guessing what would work and what wouldn't.

[jll29]

I think Rust is here to stay, but I wish folks had designed a systematic standard library (as Java has) rather than let a set of crates evolve uncontrolledly.

Hopefully, the language will develop further and then reach ISO standardization - which Java cannot as it remains proprietary.

[cogman10]

Rust's std lib approach is the best way to approach a std lib (IMO). Even in java world, some dependencies end up being the defacto standard while others end up dying off.

The JDK has a bunch of garbage in the JDK that people shouldn't use. That stuff has to remain due to strong backwards compatibility guarantees.

Rust's approach means that non-standard stuff that we end up realizing is a mistake can quietly die off.

Now, should it be larger? Probably. I'd prefer if rustlang had a standard async/await implementation rather than leaving it up to the ecosystem. But I don't think rust needs, for example, a gui api (like swing or awt) in the standard library.

I'd prefer if rust was managed a bit more closely to the way java is managed today. Java doesn't pull in new apis willy nilly, but the ones they do pull in end up being things that have broad appeal and utility. Rust could take a look at common crates in the ecosystem and start pulling those in to the standard lib.

[jasonpeacock]

Here's a good article about why Rust has a small stdlib:

https://blog.nindalf.com/posts/rust-stdlib/

[estebank]

Instead of a large std tied to the stability guarantees of the labguage, I would like to see something akin yo "stdlib distributions", where a versioned set of community libraries can be depended on to interoperate without duplicated deps in your tree. This decoupling would allow Rust to remain 1.X while the equivalent of the stdlib can bump their major version every, lets say, 3 years, without breaking older projects. You'll notice that this is almost the same thing we have today, and anyone could start it just by creating a crate called "my-std" with the list of dependencies they want to provide.

[jasonpeacock]

Why does Rust need ISO standardization - what is blocked by the lack of ISO standard?

[bigstrat2003]

Yeah, strongly agree. The lack of batteries in the Rust stdlib is by far the biggest mistake in the language.

The first reason is because the stdlib is the only thing you can always count on being there. People are often in situations where they can't download library packages due to security procedures, and have to rely on just the stdlib. People like to complain about urllib2 still being in Python even though it's not really used any more, but I've been in situations where urllib2 was the only thing available and I was damn glad it existed.

The second reason is because the way Rust does things is horribly confusing. What's the best crate to use for X? If you are a regular in the community you probably know, but a newbie is going to have no idea which of the many available options to pick. Whereas something within the stdlib is always a reasonable choice, even if it isn't the best choice.

I really hate that the Rust community in general is so dogmatic about this topic. Having so much functionality outside the stdlib makes the language worse, not better.

[steveklabnik]

I would not hold your breath for an ISO standard, ever.

MAYBE a Ruby-style "standard dump," but I don't see why such a thing would ever be useful.

[pjmlp]

Java has an official language evolution process where plenty companies take place on, several implementations and an official language specification.

Rust is yet to have at least two fully working implementations, and language specification is ongoing.

[wongarsu]

There are tradeoffs, but overall I prefer rust's "free market" solution over Pythons "batteries included". Crates can evolve, compete and innovate much more freely than the standard library can. Most importantly they can be deprecated or abandoned when better approaches are found, while anything in the standard library has to be supported forever. And when the dust settles and everyone agrees on one canonically best implementation, that sometimes does get incorporated into the standard library.

[the8472]

std promises stability to avoid a python2-3 situation. Which means any mistake we make will be with us for a long time. And we've already accumulated quite a bit of those mistakes. So non-trivial additions aren't made lightly.

Compare through how many breaking changes even high-quality ecosystems crates have gone through in the last few years.