Hacker News Reader

Comment by hintoftime | Hacker News Reader

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.

View on HN

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

https://github.com/PyO3/pyo3

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

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.

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.

Why not compile those (python scientific) libraries from source? Why would PyO3 be acceptable while e.g. numpy is not?

needing to compile them on the airgapped machine introduces more dependencies. Things also get weird when your airgapped machine is a slight version off from your dev machine. There's a lot of ways around it but we've found for the size of this tool, it was preferable to just write our own handful of math functions over building out a deployment method for extra dependencies.

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.

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.

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

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

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

I guess the GP didn't mean to point to ISO as an organization specifically, but overall standardization/specification efforts.

Still, what is blocked by lack of standardization or specification?

Many (all?) languages were successful before being fully specified, and many still are not (cough Python cough) yet that has not impacted their adoption, popularity, or effectiveness.

Many people misunderstand how software is written in regulated industries, and assume that a standard is necessary. In practice, this is not the case. Note that Ferrocene[1] had to produce a specification[2] in order to qualify the compiler. But there isn't a requirement that it must be a standard in any way, only that it describes how the Ferrocene compiler works. Nor that it be accepted by upstream.

1: https://ferrous-systems.com/blog/officially-qualified-ferroc...

2: https://github.com/ferrocene/specification

Exactly. I've heard so much "you must follow MISRA!" but MISRA is not actually the requirement - it's a solution that satisfies the requirement, and there can be other way to satisfy the requirement of your industry's regulations.

I don't think GP described lack of the language specification as a blocker for future success? It's something nice-to-have when the ecosystem has enough resources, though I'm skeptical if this can be meaningfully kept up-to-date unless the core language team decides to actively maintain it. But this will definitely trade off the velocity to a certain degree.

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.

In Java land, I can just ignore dead stdlib stuff. In rust land I have to fight bugs when two crates depend on different async or applicator libraries.

Surely you can see how one is worse than the other?

> 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.

What you are describing is a problem, no doubt about it, but it's not as if this isn't something that can't come up in javaland. For example, dealing with a project that uses both Gson and Jackson. Or dealing with a project that's mixed together Netty with Apache http.

And when you can ignore these dead libs very much depends on what the other parts of the lib you are dealing with. For example, you might never interact with `Enumeration` or `Vector` yet there are parts of the Swing api that expose those.

> I'd prefer if rustlang had a standard async/await implementation rather than leaving it up to the ecosystem

The "default" is tokio, and I think even the tokio authors would agree that it's neither suitable nor ready to be part of the stdlib.

OTOH, pollster[1] (or something like it) should be pulled into the standard library. Not particularly useful for anybody who wants async, but super useful for anybody who doesn't want async but wants to use a 3rd party crate that includes async.

1: https://docs.rs/pollster/latest/pollster/

On the async front, more work needs to be done to allow a more "plug and play" scenario for async runtimes. Standard APIs/traits for task spawning & mgmt, channels, locks, etc. Because right now it's not really feasible to write a library in an async-agnostic way, and tokio just owns the field even in places where it's not really appropriate or the best choice.

> 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.

That is not actually a problem. Let it stay there, it hurts nobody and may actually occasionally help people.

I disagree that it's not hurting.

The massive feature set of the JDK bloats the size of every container shipping with the JVM. It pumps up the requirements for metaspace. And it negatively impacts JVM startup time.

I'm not saying the JVM needs to remove every dated API. But things like JNDI, for example, are not only dangerous to use (that was the root cause of log4j2's big vulnerability), they are massive feature sets that pretty much nobody wants to use.

Java was designed in an era where we thought having thinish clients streaming jars/classes from central network servers was probably a good idea. When we thought the JVM could be more than just a language VM, it could be an operating system. A lot of those concepts simply don't apply to modern jvm dev or even jvm dev that's happened in the last 20 years.

And, to be clear, the JDK was not wrong in bringing along all these libraries. After all, in the 90s it's not like we really had a great story around community package development. That was an era where devs routinely downloaded their dependencies manually. Clever devs even had curl scripts wired into ant or make to do that job.

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.

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.

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.

(have an upvote, no idea why you're in the negative)

I have been thinking about this for the past few years, and I think I'd go so far as to make the standard library "not special." That is, make it work similar to the edition system: cargo new would add a dependency for the latest std at the time, build-std would just be transparent, and you treat it like any other crate.

That said, I am sure there are a zillion issues with this today, especially in Rust itself, but if I were to make a Rust++, this is one of the things I'd consider trying to give a shot.

The issue with this approach lies with the current content of the stdlib: the stdlib is for vocabulary types, that is, types that are meant to be used as interoperability bricks in almost all programs (think Option, Result, Vec).

If you start versioning the stdlib now you need a bridge between the Option from std1.0 and the Option from std2.0. This will become confusing quickly for programs that use libraries that depend on different versions of the std.

We could forbid that situation, but then we have an ecosystem split

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.

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.

Reply on news.ycombinator.com