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

31–40 of 93 posts

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

#31

Post by tracker1 »

steveklabnik wrote: post #20
traderj0e wrote: post #9

Is async in Rust really this bad? Last time I used Rust was before that existed. I know it's a pain in Python because they bolted it on way after, but in JS it's a breeze because everything standardized on promises early.

Rust’s async makes some design decisions that make it a unique feature: no other language has zero allocations to do async, for example. (In C++’s version you can get it to do no allocations if you do certain things, like making the required allocator a no-op, in my understanding, but it conceptually requires a call to an allocator) This makes it suitable for a much wider variety of tasks than other languages with si…

I can only speak for myself, but I kind of refused to get started with Rust until async landed... only because it's kind of a core of scalable services. I think it's pretty great in that you can use an async runtime, but still launce native threads if you want/need to for specific scenarios. It's pretty great and for most high level tasks, I wouldn't classify it as significantly more difficult than C#.

A few other things I've done with it have been written by AI as much as myself... which has similarly been pretty nice... Rust code can be very easy to reason with (lifetime syntax not withstanding). For some reason Rust lifetimes burn my soul.

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

#32

Post by tracker1 »

Aurornis wrote: post #26
traderj0e wrote: post #9

Is async in Rust really this bad? Last time I used Rust was before that existed. I know it's a pain in Python because they bolted it on way after, but in JS it's a breeze because everything standardized on promises early.

If someone finds normal ownership concepts in Rust to be difficult, making the leap to async is only going to make that worse. I don't think it's friendly to Rust beginners but I also think the complaints about if have been overblown

I think it depends on what you're doing... getting to a point where you understand Arc helps a lot, and if you're mostly using it with something like Axum, there's very little you need to worry about specific to lifetime or a lot of the burrowing logic in practice. You can definitely get by with less than perfect code.

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

#33

Post by scuff3d »

vablings wrote: post #19
scuff3d wrote: post #15

Earlier quoted context omitted.

The annoying thing about Rust, or at least the hype around Rust, is that people want to in use it for bloody everything. We have absolutely no need for it at work. We're writing micro services that run in K8s with no extreme performance requirements. Nobody on the team knows the language (I know it better than the people arguing for it, and I don't know more then the basics). And yet, every couple of weeks, I'm havin…

Because the attraction of rust is powerful. The same toolkit allows you to write code for a microcontroller or a full fat arm webserver, the rules are the same and the language is strong. The best bit about writing rust is the reason why it kinda sucks for corporations. You can "finish" your code

Thank you for so aptly demonstrating what I deal with at work.

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

#34

Post by irishcoffee »

vablings wrote: post #19
scuff3d wrote: post #15

Earlier quoted context omitted.

The annoying thing about Rust, or at least the hype around Rust, is that people want to in use it for bloody everything. We have absolutely no need for it at work. We're writing micro services that run in K8s with no extreme performance requirements. Nobody on the team knows the language (I know it better than the people arguing for it, and I don't know more then the basics). And yet, every couple of weeks, I'm havin…

Because the attraction of rust is powerful. The same toolkit allows you to write code for a microcontroller or a full fat arm webserver, the rules are the same and the language is strong. The best bit about writing rust is the reason why it kinda sucks for corporations. You can "finish" your code

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 time ago: python is the second-best language for everything, and the "first-best" for nothing.

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

#35

Post by tracker1 »

traderj0e wrote: post #8
irishcoffee wrote: post #3

This gets so old. Rust is a programming language. It does some things really well, some things less so. It isn't a panacea, it's a tool. People can use it because they like it, right-tool-for-the-job or not. People can hate it, hating a programming language is one of the most benign things to hate in the whole world. "Language-ist" is a world I never want to live in. Feels like there are some people who love rust, an…

The post doesn't hate on Rust, it's more saying you probably shouldn't use it for high-level code like a web backend. Which is pretty reasonable.

Having written web backends for three decades in quite a few languages along the way, I disagree. You can definitely write some relatively simple backends in Rust. Tokio and Axum make it quite friendly, and depending on what you are connecting to it becomes super easy, barely and inconvenience.

Even if you cheat and do a lot of cloning across library boundaries, it's still likely to perform pretty well compared to a lot of prevailing frameworks. I'd say I'm most recently most familiar with C# and FastEndpoints as well as TS/JS and Hono, but I've used many others. I've also done a bit with Rust and Tokio/Axum and it's not been significantly worse than the former mentioned options. That said, the runtime containers are a fraction of the size, start significantly faster, and use a lot less memory with Rust. And once your boilerplate is in place (jwt/oauth, db context, etc), it's roughly the same work.

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

#36

Post by ViewTrick1002 »

traderj0e wrote: post #11
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…

For the use cases the author is alluding to, you do need to use async. Non-cooperative threaded multitasking isn't a real choice for backends, and Rust doesn't have virtual threads. Before Java got virtual threads in Project Loom, people were typically using some promises equivalent even though it mangled the heck out of all your code, cause they didn't want to be doing blocking stuff with a thread pool. That was a b…

Rust had that, but decided it wasn’t a good enough fit. Which was the motivation to keep exploring and land on the current async implementation which scales from embedded to servers with minimal overhead.

History:

This RFC proposes to remove the runtime system that is currently part of the standard library, which currently allows the standard library to support both native and green threading.

https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...

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

#37

Post by Aurornis »

tracker1 wrote: post #32
Aurornis wrote: post #26

Earlier quoted context omitted.

If someone finds normal ownership concepts in Rust to be difficult, making the leap to async is only going to make that worse. I don't think it's friendly to Rust beginners but I also think the complaints about if have been overblown

I think it depends on what you're doing... getting to a point where you understand Arc helps a lot, and if you're mostly using it with something like Axum, there's very little you need to worry about specific to lifetime or a lot of the burrowing logic in practice. You can definitely get by with less than perfect code.

[dead]

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

#38

Post by NoboruWataya »

mwigdahl wrote: post #7
irishcoffee wrote: post #3

This gets so old. Rust is a programming language. It does some things really well, some things less so. It isn't a panacea, it's a tool. People can use it because they like it, right-tool-for-the-job or not. People can hate it, hating a programming language is one of the most benign things to hate in the whole world. "Language-ist" is a world I never want to live in. Feels like there are some people who love rust, an…

vi would be much easier to rewrite in Rust.

Helix is in fact written in Rust and is now a frequent contender in the editor wars.

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

#39

Post by vld_chk »

This is the case, when author argues about the right thing (you do not need Rust everywhere on every project and in every feature, especially if your team has 0 prior exposure to Rust or at least C++), but provide very awkward arguments which are not aligned with core thesis.

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

#40

Post by tialaramex »

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 time with the changed value until we succeed" stanzas some low-level people will have written a hundred times. This library feature does all that boring boilerplate for you, you just write that "calculate a new value" code as a lambda (or function, Rust doesn't mind) and you're done.

That's the sort of feature where if it didn't exist when you wrote your code, you go "That's nice" and move on, no change needed, but now that it does exist you might use it in future software you write. If you have a team writing Rust it probably makes sense to have somebody read these changelogs, but that's about it.

Post reply on HN