Hacker News Reader

I can speak to the UI question, as I'm very invested in it.

It is way too early to standardize any such thing now. There are, give or take, 5 promising UI toolkits, and a dozen others that are best thought of as experimental and may contain interesting ideas. There's a very wide diversity in approaches, and much of that diversity is not accidental but can be traced to different requirements. If you need to deploy an app both on the web and natively, then that pushes you toward adopting at least some web technologies. If you're working on games or game tooling, then the tradeoffs of immediate mode GUI are much more appealing. Another major axis is how much to rely on platform capabilities for stuff like text layout vs rolling your own.

We need to do a lot more exploration of the design space. I believe there is potential to build really compelling UI in Rust. It's entirely possible we end up with fairly different approaches for different use cases, hopefully converging on common infrastructure for things like accessibility.

But if we standardize anything we have now, it risks "the standard library is where modules go to die."

Standard library works everywhere the implementation exists, modules is hit and miss regarding supported platforms.

A moribund API provides me more value than one that doesn't exist at all.

That usual meme against rich standard libraries keeps forgetting that tiny and very important property of standard libraries.

Rust is particularly strong because the crate system lets them slowly bring things into the stdlib.

There are many UI libraries for Rust; I’ve tried most of them, and all of them are radically different in their approaches. None of them are anywhere near as good as most UI frameworks in other languages (in my opinion).

Bringing a UI framework into the stdlib at this point in time would be terrible because the community still hasn’t figured out the best way to write a UI framework and it would stifle innovation in this developing section of the language.

The website "Are we GUI yet?" lays out the current state of UI frameworks on Rust, for those interested: http://www.areweguiyet.com/

I don't understand this website and why it always get linked. It's just a list of a bunch of crates unsorted. Most of them are unmaintained, or just early prototypes. There isn't a good comparison of all these crates

We are not gui yet.

> Who doesn't prefer to just build something in a language where you know first time setup is pretty straight forward

Is first time setup of Rust projects a regular issue for you? That's not my personal experience, but I am of course biased. 99% of projects are "git clone && cd && cargo build," done. 0.95% are "oh, also install some C library via the package manager," which is a one-time thing per library.

In practice, some folks have tried to get a "richer standard library" going, and they've never seen community adoption, and so end up abandoned. It's been quite a while since this sort of thing was proposed by the project, but back when it was, the community also pretty resoundingly rejected the idea.

Having come from Ruby (where you were also a visible member of the community) I really do prefer Rust's model where the standard library is kept a bit thinner and additional functionality that would have been part of the Ruby (or Golang) standard library is kept separate.

The benefits are I'm sure not new to you. Updates and releases can be completely independent of Rust itself, and by not being in the standard library maintainers are able to deprecate and remove misfeatures when needed as opposed to having to support something that holds back a library for forever.

The one downside though is that there is the unfortunate reality that—by leaving important parts of the ecosystem to random crate authors—important and heavily-used crates which would be part of other langs' stdlib can become unmaintained over time. This hasn't been too large a problem so far, but I do wonder if more could be done to promote community adoption of crates that are perceived to be more core to the ecosystem. The nursery is probably a good approximation to what I'm looking for, but without necessarily coming along with the implication that it should ever end up in `std`.

As someone who was merging PRs into a Ruby gem for the first time in years this past week... this also happens in Ruby, ha! I've been that failed random maintainer over there too.

And I suspect standard libraries get far less 'maintenance' than many people think they do, especially compared to a popular external library.

You're not wrong, but the signaling around `rust-lang-community/http-server-async` having one patch release in two years vs `r0ckst4ar-life/tokio-hat-tip` doing the same—even if both repos host the exact same code—is (in my eyes at least) completely different.

Both could publish the exact same HTTP server crate but with one of those two, I can a) have some confidence that it's a probably a reasonable default choice, and b) assume that it's much more likely to be stable and mature than simply abandoned.

I dont mean established codebases. I mean if I ask you to build a web server in Rust how quickly do you have it up? What are those steps? I can have a Django or ASP .NET project up insanely quicker for example. Heck I can have a Go net/http project up quicker than all the above just cause of muscle memory since that package has not changed a whole lot in years, which adds to the value of Rust having an extension to their stdlib that is maintained by them.

Okay let's try it:

  〉time
  The current time is: 12:38:36.95
  〉cargo new foo
  〉cd foo
  〉cargo add axum
  〉code . (and then copy-paste the axum docs hello world from docs.rs/axum into src/main.rs)
  〉cargo build
  〉time
  The current time is: 12:43:37.44

Most of that is waiting on my crates.io index to update (which isn’t something that happens every time you start a project), and that, hilariously, the axum hello world also requires that you do a `cargo add tokio --features macros rt-multi-thread`, which they do not document, and I had to figure out myself. Most packages don't have that issue, and I'm filing a bug right now.

> I can have a Go net/http project up quicker than all the above just cause of muscle memory

I suspect that this has a larger impact on your experience than you're giving it credit for. You shouldn't discount familiarity, it's a huge bonus! And a good reason for you to do this stuff in Go and not Rust. But it doesn't mean it's universal.

Am I going to argue that Rails is not wildly productive? Absolutely not. But at least, for me, the package existing in the stdlib isn't the different factor here. Rails and Django both aren't in the Ruby and Python standard libraries either, you know?

Never used axum, what does it bring out of the box? Interesting, maybe I've been out of tune from Rust for too long, I don't get paid to work with it so it is easy to fall behind!

I'm really into things like Django and ASP .NET these days, and last I looked (months ago?) Rust doesn't offer anything fully batteries included yet (relative to those two frameworks), heck even Phoenix is really good in this regard.

There’s nothing as out of the box full of batteries as Django. Rust, like Go, tends to use a more “libraries” approach than a “framework” approach.

I like axum because it’s maintained by some prominent Tokio folks and fits my sensibilities. There’s lots of good choices out there.

On that note, how does a beginner do what you just did in under a minute? Versus, someone going through the walkthrough for Go and seeing you can make a website using net/http, because it is built-in and doing it? This is the nuance I'm talking about, built-in or at least core-maintainer supported libraries are usually easier to adopt because you know there is a lot of investment into them.

The first chapter of the Rust book covers how to integrate dependencies in your workflow. The only thing not covered there is choosing which web framework to use. To do that, you either Google it, ask around, or just pick literally any of them and give it a try.

You’ll notice the sibling comment did the same thing but with a different web framework they prefer. That’s great too. But other than the choice, it’s entirely agnostic. Another sibling even posted a step by step tutorial, if that level of specificity is helpful.

You're right that adding dependencies is easy, but you're significantly downplaying the discoverability of quality crates for specific usecases.

When people say "we need a rich standard lib" they are more interested in a "blessed set of crates" than a "it should be pre-downloaded with the compiler".

I mean I think my answer is the best anyone can do. It’s not as if there’s never packages competing with the standard library, and finding one you like and then always use is a one-time cost. There’s a ton of ways to find the answer to this question easily. It is of course true that you have to look.

While two different ones were mentioned in this thread even, a new user would be easily served by either.

Interesting, I had never tried to "build a web server in Rust" so, I read these instructions https://actix.rs/docs/getting-started and built one.

It did take about a minute to figure it out, and then I also spent another minute fiddling with the examples because I wanted to say funnier stuff.

Built, ran, checked on my local machine, very convinced, Rust makes a pretty good web server, would recommend.

I feel like that wasn't your point ?

I guess the story for doing web in Rust is different today, its a little easier, but as someone new to the language, how do I know what Actix is, or who maintains it, having watched that scene a while there was a weird scandal with Actix a few years back, the lead developer just quit or something? But on that note how do I know which web framework is best for Rust for a beginner? If I'm coming from Django, what framework gets me the same experience? I've gone through Actix docs before, and their docs were completely out of date form what cargo installed for me, it was confusing and off-putting, I didn't bother with Rust web dev for years after that.

cargo new example-server

cd ./example-server

cargo add actix-web

(quickly searches crates.io for `actix-web`)

Cool, copy and paste:

    use actix_web::{get, web, App, HttpServer, Responder};

    #[get("/hello/{name}")]
    async fn greet(name: web::Path<String>) -> impl Responder {
        format!("Hello {name}!")
    }

    #[actix_web::main]
    async fn main() -> std::io::Result<()> {
        HttpServer::new(|| {
            App::new().service(greet)
        })
        .bind(("127.0.0.1", 8080))?
        .run()
        .await
    }

takes ~a minute. Not sure std would have saved me any time, I would have just searched the stdlib docs instead of crates.io for actix. And I guess I wouldn't need to `cargo add actix-web` lol that was not the bottleneck.

How does a Rust beginner know what actix-web even is though? In Go the net/http library is discussed early on when learning Go.

I'll suggest that the Rust core team, who are very experienced and capable at making compilers, PL design, data structures, might not know much about implementing the HTTP protocol, parsing XML, or particularly UI framework design (which has driven many engineers to madness already). They should focus on the language and let the community build tools for the application layer.

Fun fact, in the pre-1.0 days Rust did try to provide a batteries-included stdlib, and came to the exact same conclusions as you have. :P In the run-up to 1.0 an enormous number of modules were jettisoned from std and into the then-new crates.io. I'm not opposed to having a larger Rust stdlib, but it is better to at least let subject domain experts hack on the problem for a while until, perhaps, the community standardizes on a de facto API.

The reason Rust has a lean std is because it must be backwards compatible, and already there are some deprecated things in std that must nevertheless be supported forever. With community crates, they can have breaking changes and can generally innovate more than those in std.

An alternative I'm not against is having the concept of "crate distros", where a bunch of related crates can be pulled in in one go with a tested set of versions. Something that delivers an experience like Django or Rails. At that point the distinction of "std" and these packages is one of nomenclature (and the kept ability to evolve independently from the compiler release schedule and remove things in the later).

It's not exactly what you are talking about, but tokio is kind of doing this - hyper, tonic, tower, tracing etc. and then all packaged together in axum.

That would be a great thing to have, but I can't imagine how that can be maintained. Managing versions of gdal+gdal-sys+geo+ndarray+ndarray-linalg has been a giant PITA recently so I for one would welcome this feature.

This seems like a self imposed limit rather than something fundamental.

I am not sure why people get so hung up on the stdlib's stability guarantees. We could have a second unstable "nonstandard" library for example, and eliminate this "issue" completely.

Even a crate "distro" like the other user said would be nice. Something to allow us to establish some level of trust over what we are using. Right now we have people mindlessly adding 100s of crates with no concern about the supply chain.

I’m the space Rust is in, people care about stability to the extreme. So some of it is self imposed, sure, but that self imposition is an understanding of what constraints the intended audience has.

Heck you can see it in this very thread with a complaint about too many new things even though they’re compatible!

I am not sure that something like a crate distro would actually cause a decrease in stability overall, at the end of the day people are still going to be using the same crates and those crates will be as stable as before, but it will be easier to figure out which ones are trustworthy for a person who isn't super deep into the rust ecosystem and whatnot!

I am thinking of nom for example, lots of people are already using nom and are comfortable with it's current level of stability, so if it was part of a crate distro people would just determine if nom was stable enough for them and use it, otherwise find something else.

I do appreciate that the real standard library and core language are stable though just to be clear. I also appreciate that the stdlib tries to stay somewhat lean rather than shoving the whole world in it.

I am just a random hobby rust user so it's very possible I am talking a bunch of nonsense!

Also thanks for replying, it's always cool to see you active in these threads :)

> I'm also thinking of my favorite things about languages like Racket and Python which is a really simple editor that is built-in.

I've heard this before but I've never really understood it.

Why on earth should language designers spend time and effort building a toy text editor when damn near everyone has VS Code, JetBrains, Sublime, some flavor of vim or emacs, etc. available to them? Why would anyone want to learn a new, completely bespoke editor just to play around with a new language when you can install a language extension for the editor you're already using in seconds?

I'm genuinely asking here. What am I missing?

If I want to build a UI and the language I'm using has a supported (yet limited but thats okay) UI stack, I can feel confident that it will not go unmaintained like third party packages for UIs. Also a lot of the UI stacks import other UI libraries in C++ or C which doesn't really make the benefits of Rust shine through.

I'm not much invested in Rust, but seeing how the C++ Committee wastes time discussing topics like a 2D graphics library or audio playback I shudder at the thought that Rust could become the same.

Also with Cargo, what's the difference between a 3rd party library and the stdlib? (none really)

The stdlib can use some nightly features in stable. Not a big issue.

Rust doesn't have the same goals as Python or Go. It remains first and foremost a systems language, where Go is first and foremost a web language.

Also: when the package ecosystem is as strong as Rust's, it's less important to supply first-party things just because they're useful, and more important to supply things that establish a common interface that multiple third-party packages can then agree on as a standard. See things like the Future trait

Are you telling me there isn't a single system in this planet without a UI? Because that sounds like a bad claim.

I would also appreciate it if the standard library had a standard for UIs so you can build something UI library agnostic, that would be really interesting to see.

Until we have languages like Rust and Go make headway with GUI stacks, we will be forever cursed to live in a world full of Electron web apps.

The systems language C++, traditionally came with rich frameworks alongside their compilers.

Nowadays it only applies to Visual C++, game consoles and embedded platforms, because everywhere else it lost the leading role for full stack development.

Right, because higher-level languages became fast enough for a lot of that stuff. Rust was born into a world where that was already true

I think Tauri could be the cross-platform UI framework you want, if they can pull off Tauri Mobile