Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The limits of Rust, or why you should probably not follow Amazon and Cloudflare

kerkour.com

Post reply on HN
Print view View original

71–80 of 93 posts

Re: The limits of Rust, or why you should probably not follow Amazon and Cloudflare

#71

Post by irishcoffee »

vablings wrote: post #50
irishcoffee wrote: post #34

Earlier quoted context omitted.

Fair points, but this glosses over some of the not-great parts. Cargo isn't great. No sanctioned formal spec isn't great. Compilation times aren't great. Messing around with wrapping foreign types can be a bit of a bear sometimes. It's a fine language, just like all the others. I'd rather write a web server in Go and a use C when targeting a micro-controller. Almost reminds me of a quote I heard about python a long t…

Sure, and that's probably because you are good with both Go and C. for me, I use rust as the hammer, and everything is a nail. Hobbyist vs Employee I guess

No, it’s for the reason you said. Not everything is a nail.

Re: The limits of Rust, or why you should probably not follow Amazon and Cloudflare

#72

Post by zesterer »

This is largely FUD, written with the intent of sounding professional and with expertise, but in practice there are many tell-tale signs that the author doesn't really know what they're talking about.

> the biggest drawback of async is the fragmentation of the ecosystem

95% of the ecosystem uses tokio nowadays. async-std has been dead for a long while. There are other runtimes for specialist purposes, but pretty much all async libraries will work with tokio, and you should just use tokio. It's fine. It's well maintained. It's not going anywhere. It's hit a stable 1.0. There is basically no reason to not use it.

> So, if you think that you didn't have enough work solving the problems of your users, you now also need to update your toolchains, Dockerfiles, dependencies and more, every 6 weeks.

This is complete rubbish. Rust's edition system means that Rust code written back in 2015 will (largely, bar some minor soundness issues that have been found since then) still compile. You're under no compulsion to update anything, and cargo's lockfiles ensure that your builds don't suddenly break. If you want to upgrade, do so! But it's exceedingly rare that code ever needs to change when doing so. It's about a painless an upgrade experience as it's possible to have in this industry.

> Rust is betting everything on a powerful language backed by advanced theory, but it forgot that developers need more than a language to build solutions to businesses' problems.

No, it didn't. Rust's standard library is not designed to give you everything you need to build a large program. Instead, it's designed to specify the interfaces that other libraries in the ecosystem require to talk to one-another, and it's been remarkably successful at that. Take a scroll through [the docs](https://doc.rust-lang.org/std/) and you'll see that: it's almost all traits, fundamental types, and other shared abstractions that are used by the rest of the ecosystem. Any non-trivial program is supposed to end up with third-party dependencies: the critical thing is that those dependencies can talk to one-another painlessly, and that promise is largely delivered upon: everybody uses the same interface for `Future`, `Iterator`, `From/`Into`, `Allocator`, `Clone`, `Eq`/`Cmp`/`Hash`/`Ord`, `Error`, `Debug`/`Display`/`FromStr`/`ToString`, `Read`/`Write`, `Sync`/`Send`. That's the sign of a remarkably successful and well-engineered set of abstractions.

Re: The limits of Rust, or why you should probably not follow Amazon and Cloudflare

#74

Post by dev_l1x_be »

I am not sure how many times RIIR helped me, my customers, teams to achieve better outcomes. Energy use matters. Memory safety matters. ML (Meta Language) features are a bliss to C/C++ languages. With the coding agents picking up Rust is much easier than it was 5 years ago. I am not sure what impact the lack of crypto primitives in the standard library even has. I can use hashing (even the more advanced ones like blake3) and some of the NACL primitives and that is fine.

Async Rust is a bit hard, I agree. Function coloring is probably not the best, but I am not sure how to not have that in a compiled language like Rust, or how to improve it.

Re: The limits of Rust, or why you should probably not follow Amazon and Cloudflare

#75

Post by saghm »

simon_void wrote: post #66
bryanlarsen wrote: post #44

Earlier quoted context omitted.

And all the popular ones include a synchronous interface you can use instead of the async one. If if they don't, you can wrap your calls in spawn_blocking. You might complain about it pulling in tokio, but that's a very different complaint than having to learn/use async.

Is the inclusion of synchronous interfaces a new thing? When I learned actix_web 2-3 years ago for some webservices at work, the documentation surely (at least) started of with async functions everywhere. Did that change? Were synchronous interfaces introduced later in the actix_web documentation? Or did everybody switch over to axum in the meantime and axum has synchrounous interfaces!? (I just checked and according…

You seem to have picked the framework where the selling point is literally providing an async actor model, so yes, it's probably going to be async. If you don't like async, you probably should be spending time getting experience with one of the frameworks that's less opinionated.

Re: The limits of Rust, or why you should probably not follow Amazon and Cloudflare

#76

Post by saghm »

ben-schaaf wrote: post #13

> Between January 2020 and May 2026 Rust has seen 54 releases, which amounts to 7500 lines of changelog. > During the same period, there was 12 Go releases, 12 Node.js releases (but only 2 LTS) and 5 Python releases. Some corrections: Rust saw 54 (I assume that's correct, I didn't recount) minor releases, with a few minor breaking changes. If we only count editions there were 2 releases, but again those don't break b…

Yeah, it's pretty weird that they're hating on the six week release cadence because...they think the changelogs are too long? Just don't read them then!

Re: The limits of Rust, or why you should probably not follow Amazon and Cloudflare

#77

Post by saghm »

tialaramex wrote: post #40
pornel wrote: post #23

It's a rehash of a bunch of old misconceptions. I thought we've buried these when people got actual experience with Rust. The dumbest one is counting changelog lines. Have you even read them? These days most of them are "obscure libstd function is now allowed in const contexts". The regular Rust releases include compiler improvements, libstd evolution, and build system tweaks. Nobody's saying C keeps changing because…

I agree but more common than "Now allowed in const context" is "This new type/method/free function is now stabilized" e.g. in 1.95 they stabilized a bunch of "Atomic update" methods such as: AtomicPtr::update which is a nicer way to write one of those "Get the pointer, do some stuff to calculate a new value from the old one, then try to swap its old value for the new one, if the pointer changed meanwhile repeat each…

I tend the be the one on my team who reads them. I don't think I've ever had a coworker in close to seven years of writing Rust professionally that had trouble because they didn't read them. At most, sometimes I'll suggest using some function I remembered reading about to someone in a code review, and then they'll go "oh, cool!", and use it, and then they don't need to do anything else. Meanwhile, the times that there are useful changes under the hood, you get them in a few weeks instead of maybe some time later in the year or next year.

I don't understand at all how someone could plausibly argue that this is a problem in this context. At absolute most, you could argue against some of the downstream effects of the rapid release cycle (like how it reinforces the small standard library size; more surface area means potentially more bugs, and putting out an extra release to fix them when there are already releases so frequently is a hard sell, so it makes sense to keep things slim), but the article doesn't have anywhere close to that level of nuance in addressing the issue, so I'm skeptical that this is even something they've considered.

Re: The limits of Rust, or why you should probably not follow Amazon and Cloudflare

#79

Post by mkj »

aabhay wrote: post #16
ben-schaaf wrote: post #13

> Between January 2020 and May 2026 Rust has seen 54 releases, which amounts to 7500 lines of changelog. > During the same period, there was 12 Go releases, 12 Node.js releases (but only 2 LTS) and 5 Python releases. Some corrections: Rust saw 54 (I assume that's correct, I didn't recount) minor releases, with a few minor breaking changes. If we only count editions there were 2 releases, but again those don't break b…

Ring is a de facto standard for better or worse. In our codebase we basically have no choice but to use it

The rustcrypto crates seem a lot better maintained and will probably supplant ring in future. Ring maintenance seems hostile to use outside of expected use cases.

Re: The limits of Rust, or why you should probably not follow Amazon and Cloudflare

#80

Post by nextaccountic »

Aurornis wrote: post #2

Lots of tortured logic in this post. 1. You shouldn't pick a programming language the team doesn't know. That's common sense, not an argument against Rust. 2. Rust ranks lower on the most used languages list because it's newer than Java, Python, C, and all of the others higher on the list. 3. You don't need to use async Rust. If you do, I disagree that it's as hard as this is implying, but I would agree that it's not…

> 5. If you want a batteries-included standard library I agree that you should pick Python or Go instead.

But then you should be warned that, among the various http clients Python has in their stdlib, none should be used. Or the many datetime libs in the Python stdlib, they should not be used. LLMs know this by the way and will reach for actual best practices

Post reply on HN