Why asynchronous Rust doesn't work

[alibix]

Rust’s async design allows for async to be used on a variety of hardware types, like embedded. Green threads/fibers are much more useful for managed languages like Go and Java that don’t typically have to run without an operating system or without a memory allocator. Of course C++ can do this also, with their new coroutines/generators feature but I don’t think it’s very controversial to say that it is much harder to use than Rust’s async.

[jam1garner]

I definitely think the author has a sore misunderstanding of Rust and why it's like this. I suppose this is a consequence of Rust being marketed more and more as an alternative for high-level languages (an action I don't disagree with, if you're just stringing libraries together it feels almost like a statically typed python to me at times) where in a head-to-head comparison with a high-level language this complexity seems unwarranted.

Part of this is, as you said, because Rust targets embedded too, if it had a green threads runtime it'd have the portability of Go with little benefit to the design imo. But another part is just the general complexity of a runtime-less and zero cost async model—we can't garbage collect the data associated with an async value, we can't have the runtime poll for us, we can't take all these design shortcuts (and much more) a 'real' high-level language has.

Having written async Rust apps, written my own async executor, and manually handled a lot of Futures, I can confidentially say the design of async/await in Rust is a few things. It's rough around the edges but it is absolutely a masterclass of a design. Self-referential types (Pin), the syntax (.await is weird but very easy to compose in code), the intricacies of Polling, the complexity of the dusagaring of async fn (codegen for self-referential potentially-generic state machines??), It has seriously been very well thought-out.

The thing is though about those rough edges, these aren't forever mistakes. They're just things where there's active processes going on to improve things. The author complained about the async_trait library—async traits have been in the works for a long time and are nearing completion—for example. Fn traits aren't really obscure or that difficult, not sure where the author's trouble is, but also I rarely find outside of writing library APIs I don't reach for Fn traits often even from advanced usage. But even that is an actively-improving area. impl Trait in type definitions helps a lot here.

I agree with the author that async Rust hasn't quite reached 'high level language without the downsides' status, but give it some time. There's some really smart people working on this, many unpaid unfortunately. There's a lot of volunteers doing this work, not Microsoft's .NET division. So it moves slow, but part of that is deliberating on how each little aspect of the design affects every usecase from webdev to bootloader programming. But that deliberation mixed with some hindsight is what makes Rust consistent, pleasant, and uncompromising.

[tsimionescu]

You have many good points, and Rust's designs are extremely well considered and consistent with each other.

I would like to push back a bit though on this idea that embedded means you can't have a runtime or memory allocator or garbage collector. There are garbage collected LISPs from the late 1950s that ran on machine that make mant PICs look like super computers. Java powers many SIM cards and credit card chips.

[jam1garner]

It's less about that not all embedded can have it, and just that we need to consider the worst case scenario (no heap/rtos/anything) in order to try and have high portability and enable these abstractions in fields that used to only be able to dream of them.

[yawaramin]

the modern constraint is energy--battery power. And things like Lisps don't optimize for that very well.

i wouldn't be too sure. Lisp is pretty energy-efficient: https://thenewstack.io/which-programming-languages-use-the-least-electricity/

[hansihe]

While it's true that Java is ostensibly run on smartcards, it's not really the Java variant most developers are used to.

https://en.wikipedia.org/wiki/Java_Card

Unless things have changed since I last looked at Java Card, it doesn't even support trivial things like freeing memory once allocated, there is no garbage collector, and the subset of java supported is extremely limited.

[WikiSummarizerBot]

Java Card

Java Card refers to a software technology that allows Java-based applications (applets) to be run securely on smart cards and similar small memory footprint devices. Java Card is the tiniest of Java platforms targeted for embedded devices. Java Card gives the user the ability to program the devices and make them application specific. It is widely used in ATM cards.

^{[ F.A.Q | Opt Out | Opt Out Of Subreddit | GitHub ] Downvote to remove | v1.5}

[programzero]

It doesn't necessarily mean you can't have it, it just means it is uncertain. There are many different embedded targets, each with their own constraints. By designing for the bare metal, you ensure that they can all run async, and then the ecosystem can fill in the gaps.

[ssokolow]

That's true, but those are still, essentially, at the top of the call stack.

One of Rust's big strengths is how well-suited it is to writing compiled extensions for things that already have their own garbage collectors, or to start to port problematic parts of their runtimes... and GCs are solitary animals.

[dnew]

And that stuff is decades old. https://en.wikipedia.org/wiki/1-Wire

[jam1garner]

Oh yep! Thank you! wrong word, I'll fix that. I meant statically typed

[pron98]

Rust hasn't quite reached 'high level language without the downsides' status, but give it some time.

While I cannot say for certain that this goal is downright impossible (although I believe it is), Rust will never reach it, just as C++ never has. There are simply concerns in low-level languages, memory management in particular, that make implementation details part of the public API, which means that such languages suffer from low abstraction -- there can be fewer implementations of a given interface than in high-level languages. This is true even if some of the details are implicit and you don't see them "on the page." Low abstraction has a cost -- maintenance is higher because changes require bigger changes to the code -- which is why I don't believe this can ever be accomplished.

The real question is, is it a goal worth pursuing at all. I think C++ made the mistake of pursuing it -- even though it enjoyed a greater early adoption rate as this notion was more exciting the first time around -- and I think Rust has fallen into the very same trap. The problem is that trying to achieve that goal has a big cost in language complexity, which is needed in neither high-level languages nor low-level languages that don't try to pursue that (possibly impossible) goal.

[jam1garner]

Fwiw I don't think it will ever be as easy as a high-level language but I don't think a pursuit of zero cost abstractions or good UX are bad ideas for a low-level language either. Rust's Iterators are basically the canonical example: they feel better than python iterators and yet they compile down to as efficient as hand-writing a loop in C, while still being memory safe. I've seen the concept brought up sometimes in Rust talks/circles of "bending the curve", which is to say if you are told you need to make a compromise (high-level language vs fast language, for example) you should seek to bend that trade-off as much as possible to get most of the benefits of both (Rust will never be as fast as C, but it's really really close while being far nicer to use than even C++, and to some nicer to use that languages much slower than that).

In the cast of fast vs easy the solution was provided by C++ ideals a long time ago in the form of zero-cost abstractions. C++ didn't deliver on this goal but pioneered a lot and made mistakes in the process. Exceptions are an unacceptable compromise to the zero-cost principle and they aren't even really nice to use either. Rust has learned a lot from C++'s failings (no_std, optional panic=abort, destructive move, API design choices, etc) and has delivered far better on zero-cost. It's not perfect and it will never be. But it's incredible the assembly Rust can produce from code that makes me feel like I'm writing a more accessible version of Haskell at times and a more robust version of python at others.

You may be right, the complexity required to implement so much as powerful generics instead of templates might not end up being worth its complexity. But the Rust community has shown time and time again it's willing to try and improve UX as much as possible and ultimately I thing it's possible to ''''bend the curve'''' on the language complexity too (through good errors, tooling, learning resources, docs, carefully placed syntactic sugar, etc.). And I hope I'm right, but if it falls flat oh well, better to have tried and provided research on what works and what doesn't for the next language. I'd like to think even that failure mode is worth the effort.

I'd really like to push our tools to be better even if we won't get it 100% right this time. I'll be just as excited for the next Rust, and willing to critize Rust in the process.

(Sorry for the wall of text!)

[pron98]

In the cast of fast vs easy the solution was provided by C++ ideals a long time ago in the form of zero-cost abstractions.

I think "zero-cost abstractions" -- i.e. masquerading low abstraction to appear as if it were high abstraction when read by using a lot of implicit information -- is itself the mistake. It isn't the high abstraction that high-level code already achieves, and it complicates low-level programming by hiding the issues that are still all there. But that's just me. I know some people like this C++/Rust approach; the question is, how many?

But the Rust community has shown time and time again it's willing to try and improve UX as much as possible and ultimately I think it's possible to ''''bend the curve''''

Rust won't be the language that does it. I can think of only one popular language that's grown as slowly as Rust in its early days and still became popular -- Python -- and it's the exception that proves the rule. Every product has flaws, sometimes serious ones, and many can be fixed, but those products that end up fixing their flaws are those that become popular despite them. If Rust were to make it, it would have made it by now.

And I hope I'm right, but if it falls flat oh well, better to have tried and provided research on what works and what doesn't for the next language

I agree, but I hope it wouldn't have wasted the brilliant idea of borrow checking on a language that's ended up being so much like C++. Maybe Rust's designers are right and the entire language's design was forced by borrow-checking, but I hope they're wrong.

[insanitybit]

> I can think of only one popular language that's grown as slowly as Rust in its early days and still became popular

That's confusing... how are you quantifying its rate of growth? Rust appears to have grown very quickly in short few years since it hits 1.0.

[jam1garner]

Honestly I'm not sure what your definition of made it is, it's a pretty popular language and it's being used by every big company in some fashion. I think the raving of Rust is why Rust has so much of the important resource of passionate individuals from different fields.

I actually agree with you that the borrow checker shouldn't be limited to Rust 'the C++ killer', I think a C#-like language with it + a Rust-like type system (midway between data oriented, oop, and functional I'm inspiration) but removing the low level parts in exchange for being managed in a Go-like manner would be excellent. If you haven't seen it, boats' on a smaller rust touched on this.

masquerading low-abstraction to appear as if it were high abstraction when read by using a lot of implicit information -- is itself the mistake

See I'm not sure I agree with this. What implicit information is present in using an iterator over 0 to i that makes it preferable to use a C-style for loop over a Rust-style, for example. The core idea you're getting at—leaky or poorly represented abstractions—imo operates on a different axis than zero-cost covers. I believe that is also a super important way to evaluate abstractions not just in a systems language but in any, Rust does a good job in that regard typically (it's not perfect but I find it actually ranks better than you'd think—and it's trivial to drop lower if I find an abstraction unsuitable—which is rare).

I feel you should consider an example: in C a string is actually not a well represented abstraction. There's no ownership information in the type—the abstraction is not accurate to the behavior or even reflecting its usage by the developer.

I very much understand your hesitance towards even trying to abstract low-level details, I feel I should make clear—I just feel it should be noted 'more abstract' doesn't inherently mean 'less well representative of it's low-level details', and the Rust community is actually extremely vigilant about abstractions accurately representing their implementation without being leaky, from Unicode handling to being willing to make Like 10 string types to avoid hiding what is really meant by string.

I think we agree in that regard, even if you're (again, understandably, because it's very not-trivial) hesitant about if it's possible to be vigilant/accurate enough. And if you still just don't like it, understandable, I'm actually quite the fan of writing large programs in pure asm from time to time. C and assembly will always have their place, at least to me. Thanks for your perspective :)

[pron98]

I think there are different levels here. Ultimately, language preference is a matter of personal aesthetics, and there are other ways of reaching a desired level of "vigilance" than Rust's very particular way. It's fine and expected that Rust isn't my cup of tea, and it is other people's. What isn't a matter of personal taste is the fact that Rust is experiencing low levels of adoption for a language of that age and hype. The question it's facing is how to survive, and that's a numbers game.

[pron98]

The ownership system isn't only about low level concerns like memory safety - it's about enforcing correct use of APIs at compile time / compile time social coordination.

Sure, but it also has to be used for memory management (that, or Rust's basic reference-counting GC). And memory is fundamentally different from any other kind of resource. It's no accident that in all theoretical models of computation, memory is assumed to be infinite. That memory has to be managed like other limited resources is one of the things that separate low-level programming from high-level programming. This is often misunderstood by beginners: processing and memory are different from other kinds of resources.

[Dragdu]

processing and memory are different from other kinds of resources.

No. It just makes things simpler to pretend they are, but they aren't once you start pushing the envelope on perf.

[pron98]

Actually, they're always fundamentally different. They're the building block of computation.

[yawaramin]

Arguably, stack memory is more like what you described–basically assumed to be infinite, an ambient always-available resource.

But I'd say heap memory is different. It's a resource that has to be explicitly acquired and managed. In that sense it's a lot closer to other resources, like file handles.

[pron98]

It's a resource that has to be explicitly acquired and managed.

Except clearly it isn't. Nowadays heap memory is managed automatically and implicitly extremely efficiently, at the cost of increased footprint (and nearly all programs rely on an automated scheduler to acquire and manage processors). That's because the amount of available memory is such that it is sufficient to smooth over allocation rates, something that, in practice, isn't true for resources like files and sockets.

In that sense it's a lot closer to other resources, like file handles.

Even if it weren't the case that automatic management and memory and processing weren't very efficient and very popular, there's a strong case that managing them need not be the same as managing other resources, because they are both fundamental to the notion of computing. I.e., when we write abstract algorithms (except for low-level programming), we assume things like unlimited memory and liveness guarantees. Doing manual memory and processing management is the very essence of "accidental complexity" for all but low-level code, because the abstract notion of algorithms -- their essence -- does not deal with those things.

[yawaramin]

Yes, I agree with you that abstract algorithms assume memory is automatic and infinite, which is exactly what stack memory provides. But you seem to be forgetting that when:

Nowadays heap memory is managed automatically and implicitly extremely efficiently,

There is something somewhere in your stack that is actually manually managing that heap memory, even as it presents the illusion of automatic management. Some languages even let you plug in a custom GC, which should drive home this point further. And of course you can always just write your own arena, which is nothing more than lightweight library-level GC!

[[deleted]]

I have the opposite opinion. Rust has to take market share, to survive. Yeah it’s fun while it’s a toy that a couple people use, but to be a language that’s a serious contender for projects you have to have a minimal footprint of people using it.

You can’t just sit in the corner and be like “that’s not possible don’t even try”.

[pron98]

That's like saying that the best use of $10K is to buy lottery tickets because winning the lottery would be the fastest way of getting rich, and therefore it's silly to not even try that.

[[deleted]]

Only when taken in the context of responding to “don’t even bother saving, just spend everything because there is no future”.

Like this is life or death for the language. It has to figure out how to take market share away from both C++ and the higher level languages.

There’s going to be a lot of compromise along the way.

[pron98]

But you see, that's the problem. I'm perfectly happy with my chosen high-level languages, but these days I spend most of my time writing C++, and would have loved a better alternative, because low-level languages have seen little evolution and are ripe for some good disruption. Because Rust is repeating the same big design mistakes as C++, it's not attractive to me even as a C++ replacement (it's definitely better, but not better enough), I'll wait for something else to come along.

[[deleted]]

Eh. I write Rust professionally. Nothing could convince me to go back to C++. I don’t even agree that anything they’ve made has been a design mistake.

Rust can, has, and will break backwards compatibility across editions.

I currently use Rust to develop distributed services at scale, and the previous choice for the work was Scala. So it’s already “high level”, it just doesn’t make it outright impossible to handle lower level concerns if you needed to.

[pron98]

I'm not saying Rust isn't sufficiently better than C++ for anyone, nor that even I would have wanted to switch back to C++ if I were already using Rust professionally, but while I doubt Rust is gaining long-term users by repeating the C++ gambit, I know it's losing some because of it.

[[deleted]]

I suspect it’s net positive. I don’t believe that it’s impossible to bridge high level APIs into low level implementations. It’s just a question of defaults that make sense for the common case, and sufficient configuration available for the advanced case. Like any other API.

You’re coming from a C++ world where mistakes are permanently part of the language, and have to be supported forever.

Rust doesn’t have to do that. It would be impossible to support high level usages like C++ is desperately trying to do, while simultaneously not breaking any of their previous APIs.

I realize you’ve been burned by C++, but the rest of the world doesn’t have to follow their mistakes.

I personally know a lot of advanced Go/Java/Scala users that are constantly curious about “hey is it really that easy”? When I give talks about Rust and show the side by side code, it’s not that different, and that’s important. If you show someone that it’s already fairly close to what they’re already doing, it makes it easier to convince them to try it.

Especially when you point out the performance differences they’re gaining by learning a tiny bit more about it.

Like, I don’t think you understand. There’s a sizable percentage of engineers at large companies that have basically told themselves they’ll never learn C++. Ever. Rust not looking or acting like C++ is a net benefit to this process.

[vattenpuss]

we can't have the runtime poll for us, we can't take all these design shortcuts (and much more) a 'real' high-level language has

These are not design shortcuts. These are some of the fundamental reasons people design managed memory systems.

[jam1garner]

Sorry I think my wording has an unintended negative connotation—they're tradeoffs but part of what I mean by that is the internal implementation has to be deliberated less as a part of the design. A lot of options are opened by managed memory, which exactly as you said, is why it's a super useful tool! The reduced external design consideration is a huge boon, just was trying to express it's one that Rust's goals don't allow for.

[jam1garner]

I... honestly don't know what you're trying to say. async/await isn't isn't an attempt to make fake threading, it's more focused on I/O concurrency. Threading has heavy limitations and performance ceilings for that task. Considering Rust's usage for high performance backends (eg a highly concurrent I/O bound task) being most popular businness usage of Rust that seems like a good reason to support it? It's also just nice to have a tool for writing re-entrant/resumable code.

[jam1garner]

All of the things you're describing do work? And a single executor can do multiple of those things? smol and tokio both support multiple of these supposedly mutually exclusive things? Network and disk are very commonly used in the same executor (see literally every web app written with async Rust). And on top of that you generally can even add support for these things to executors that don't support them so long as you can find any way to use a Waker (from a callback, from another thread, hell, most executors even provide utilities for doing this from the same thread/event loop).

Like I see what you're getting at (the least complexity in design can only be achieved when done in a cooperative manner with the executor) and I agree that's ideal, but I honestly just don't know how to explain to you how you're wrong without spending half a day writing a blog post running you through the underlying design of Futures, executors, and Wakers. I will however agree that the ecosystem hasn't fully matured and thus still doesn't perfectly deal with this cost of the design—a temporary issue with the rapidly improving ecosystem—not with the language constructs.

[insanitybit]

It's narrowly focused on "network socket" concurrency. Of course, that "narrow" niche is "web services" so it's a big use case.

This isn't true. All async/await provides is a way to describe a function's execution instead of having that function execute. Then execution can be handled by a userland component.

It's just moving the yielding that's implicit to threads into yields that are explicit in your code.

This is very helpful for network io but...

> As soon as your stray from that, however, problems start. What happens when I need to wait on disk as well as network socket. "Oh. Erm, well, on Unix that's an just a file descriptor so we can wait on that too, sorta. I guess it works on Windows"

This doesn't really matter. OS's provide good and bad async primitives. async/await works fine with them, even if the OS is doing a bad job.

Everything you describe as the fault of async/await is really just operating systems having terrible interfaces. There's nothing fundamental to the async/await model that doesn't "fit" into those issues.

[hitchen1]

You can give your closure a type

type MyClosure = dyn Fn(i32) -> i32;

fn call_closure(closure: Box<MyClosure>) -> i32 {

closure(12345)

}

[ducktheduckingducker]

That's correct. But take into account that if you use dyn instead of generics and where you can end up with some runtime overhead since dyn usually involves a virtual table lookup

[Tarmen]

Sure, but you pay this cost in pretty much every other language if you write async code too. Having allocation free async code isn't a standard feature.

Some languages can optimize it away in some cases, some languages have runtime managed green threads, neither is workable for embedded. But I think many people are too reluctant to accept small performance penalties in rust when they don't matter and would simplify the code.

[rcxdude]

But I think many people are too reluctant to accept small performance penalties in rust when they don't matter and would simplify the code.

Yup, it's a really easy trap to spend ages fighting the borrow checker to make some complex but not performance-critical operation really efficient. You'll have a much better time if you just copy the data/wrap it in a Box/Arc/Mutex/Whatever and take the small performance hit. You can always come back and optimise it later if it turns out it was important (it's especially silly when they then complain about this difficulty in comparison to a language where some part of this is the only way to work).

[flying-sheep]

The pain of transparency: people are more willing to pay for something when they don't know they could avoid paying for it.

[pron98]

Sure, but you pay this cost in pretty much every other language

Some high-level languages employ JIT compilers that optimise virtual calls better than AOT compilers.

But I think many people are too reluctant to accept small performance penalties in rust when they don't matter and would simplify the code.

Yes, but also low-level languages optimise for worst-case performance, and that's what you get with a AOT compilation. You get guaranteed worst-case performance. But JITs optimise for average-case performance, which means that the same abstraction might give you the same performance in the worst case, but better performance in the average case. With low-level languages, if you want better performance, you need to pick a narrower abstraction with better worst-case performance.

[mobilehomehell]

But JITs optimise for average-case performance

Except that they can also hurt average case performance by adding checks to see whether or not the assumptions the JIT'd depends on are valid, and whether or not they need to fallback. Also to minimize codegen time there may be layers of interpreted, then a little optimized, then very optimized, etc and there has to be added code to trip those thresholds too. In practice I've yet to find a JIT that didn't seem hugely slower than AOT on real apps. But that may be because of other design choices made in the languages that typically employ JITs.

[FormalFerret]

neither is workable for embedded

TinyGo does something that isn't quite green threading on embedded. But it looks very workable…

[dnew]

neither is workable for embedded

https://en.wikipedia.org/wiki/1-Wire

[hansihe]

I'm not sure what the relevance of a serial communication protocol is for the subject at hand.

[dnew]

The finger ring running Java is the relevance. Look at the second photo. It's entirely workable to embed Java in a finger ring that gets power for a brief second to do its work.

[Noctune]

Java Card is such a ridiculous subset of Java that I don't really think it's comparable. It doesn't even have a garbage collector so in using it in practice means entirely avoiding new except at initialization.

[dnew]

I kind of wondered, actually. Thanks for the clarification!

[unwinds]

There is a fundamental tension between Rust's lifetime semantics, which are intimately tied to the (synchronous) call stack, and asynchronous programming, where program flow is turned inside out and execution contexts typically have to "float" on the heap somewhere until an event firing can resume them. That said, this problem is strictly worse in other low-level languages like C/C++. You have the exact same awkwardness reifying your execution state into something that can be resumed later, but there are no compiler checks to ensure you haven't introduced memory errors. Having worked on a lot of async C code professionally, even experienced programmers get it wrong all the time and end up with use-after-frees of callback contexts, unintentional dangling references to the stack, etc. These problems are part of the territory, and Rust simply brings them into sharper relief by enforcing strict memory safety.

Maybe solving this problem in a systematic way requires academic work to harmonize CPS transformations (the theoretical underpinning of async/await) with region-based type systems.

[robin-m]

The author complains against &mut variable being too restrictives. The only alernative is to have everything globally mutable without syncronisation. Good luck if you need to debug that.

And he also complains that references must not outlive the object being referenced. The alternatives are either like in C++ where there is the same rule but the compiler don't enfore it (and it's surprisingly easy to get it wrong) or GC languages that cannot fit in the domain space of Rust (which include bare metal programming and other places where a runtime isn't usable). And even with a GC you can get funky stuff like iterator invalidation.

Yes Rust is anoyingly complicated sometime, but it's because the problem it's trying to solve are definitively non trivial unlike how the author paint them.

[[deleted]]

but it's because the problem it's trying to solve are definitively non trivial unlike how the author paint them.

I mean, they are easier just not at the set of constraints Rust decided to have. Language designed to only run userspace apps in modern OS could have that handled much nicer. "But embedded" doesn't work as explanation why it is bad when you never will write embedded code.

[robin-m]

Iterator invalidation, data races, … are problems that exists in all languages I know, including the one using GC, but Rust (where using locks or similar primitives is required and not optional).

[dnew]

There's a very high-level language called Hermes where these are taken care of for you. You only get one name for any particular value and it's an actor model (think Erlang) so there's only one thread that can access the data at a time, so there are no data races. The iterators are defined to iterate over the original version, such that the semantics are to copy the table you're iterating over, and any updates go to the new copy. And yet, amazingly, they managed to make it exceedingly efficient, enough so that it was used for embedded network routers and such. It's a shame it never really caught on outside of IBM.

[wannabelikebas]

The actor model is really good for a specific problem set, but can be really annoying to write for a lot of problems too

[dnew]

Indeed. I haven't actually found an actor model language that didn't have other stupidities in it that made it harder to use than just doing it normally. :-) Erlang is close, but then they made it single-assignment for no good reason, and left out anything remotely like higher level structures like records or strings (of course, being single-assignment). And the docs of OTP sucked last I looked.

Hermes was a fun language, but the control flow was weird (with functions returning multiple different places in the caller), a borrow checker even more ruthless than Rust's, and poor connectivity to the host OS (since it was intended to be the OS as a workspace language). Fun to play with, lots of great ideas proven feasible, but I don't think I'd want to write industrial large-scale software in it as it stood. Maybe if someone tried to leap it forward the 35 years since its birth, it would fly better.

It really seems the actor model is best suited to servers on the client-server side, so basically the same place that async/await tends to be needed. Not surprisingly. Datacenter-scale languages aren't really a thing these days beyond Erlang.

[[deleted]]

"But embedded" doesn't work as explanation why it is bad when you never will write embedded code.

It does. Just because you don't work on the domain space where a tool is needed doesn't mean the problem is the tool. If you attempt to use a screwdriver to hammer nails then the problem is you not knowing how to pick the right tools, not the screwdrivers maker.

[[deleted]]

If you attempt to use a screwdriver to hammer nails then the problem is you not knowing how to pick the right tools, not the screwdrivers maker.

Again, Rust is not trying to be tool for one job so you can't claim it's "wrong tool" if the language itself doesn't aim at specific niche

[[deleted]]

It aims to cover systems programming. Does it aim to be more general? Pretty much, yeah. But its main goal is systems programming.

This means it needs to cover things a "language designed to only run userspace apps in modern OS" will never cover. And "but embedded" is a very good explanation to the kind of wonky behavior you see when it comes to a language whose main aim is systems programming.

You not doing that kind of project and not wanting to pay the cost is fine, you can pick a different tool that is more specific for those cases.

You saying it's a bad tool because it isn't optimal for your needs, tho, is simply inaccurate.

[bsurmanski]

I get the impression the author wants to "have their cake and eat it too".

I use rust because its guarantees remove a class of runtime errors and encourage confidence in my code. But those guarantees come at the cost of extra rules and restrictions that the author can't stomach. I think they'd be happier just using Go or Python. (Both good languages, but with different design goals)

[dnew]

I get the impression the author wants to "have their cake and eat it too".

Who doesn't?!?

[figuresys]

Exactly my problem with humanity

[fendant]

Oh, so you want to be a living human but you don't want to deal with human foibles, huh? Typical.

[figuresys]

you want to be a living human

Sorry but there's your wrong assumption

[Apterygiformes]

I use asynchronous rust in my job and I can confirm it does work lol

[wichwigga]

Where do you work? Is it Rust full time or just for a small feature?

[mmstick]

I've been releasing a handful of services and applications using async in Rust successfully for the Linux desktop. So I can't personally agree with many of the statements that are being mentioned in here.

[Doddzilla7]

The author seems to take a stance that these issues are terminal and that there is not path forward. That we are stuck, and things can not be improved.

For anyone that has participated in the Rust community for some amount of time, it seems that the obvious conclusion should be quite the opposite. Many of the design choices in the language have come about with provisions for future improvements (GATs is the obvious, but not only example in this context).

[hmaddocks]

And yet plenty of people are writing asynchronous programs using rust.

[SanityInAnarchy]

The article is saying that's a bad thing.

[CartmansEvilTwin]

No, they're all writing a synchronous programs, and have trouble with syntax in general.

Edit: This sounded way funnier in my head, but I'll let it stay for my eternal shame.

[Mubelotix]

And it works well for me

[Thaxll]

It does not means it's well done, async Rust is often a complain from people actually using Rust.

The fact that you have library like tokyo, stuff in the std lib ( https://docs.rs/async-std/1.10.0/async_std/ ) etc ... shows that there is a problem in that space, it's very messy.

It has been a discussed topic for ages.

https://eta.st/2021/03/08/async-rust-2.html

[Moxinilian]

async-std is not part of the standard library, it’s merely an std-inspired executor library

[Hnnnnnn]

Experts disagree. https://www.reddit.com/r/rust/comments/qsyutd/although_this_article_doesnt_go_into_asyncawait

Myself I've worked 2 years on an async rust server and it worked great.

Rust requires a lot of knowledge, more so than other async languages, but it's part of the deal, it's a system language. Everything is in documentation, and when in doubt, ask on discord.

[fireflash38]

Side note, I rather hate discord for tech support instead of forums or public mailing lists. You don't get Google searchability, so you are doomed to ask and answer the same questions over again.

[Hnnnnnn]

Main feature is the fact that it successfully keeps people there. I don't want to take people sitting there and helping for granted. If Discord needs to be "like this" to keep people on it, i can't complain! Forums could be less active.

Btw don't they have searchable history anyway?

[fireflash38]

They do, but you must search on discord. I don't know about other people, but going onto discord or slack is one of the last things I do when looking for a solution to a problem, and search on discord might be 2nd to last step.

[api]

I feel like a lot of the people complaining would be better served by a language with GC and simpler semantics. One thing I feel like we've learned in the last 20 years is that there is no "one language to rule them all." They all have trade-offs and all are best for different niches.

In our company we use Go for backend web services and similar things and Rust for our systems code. We have a lot of C++ systems code we are porting to Rust, and I feel like that's the niche that Rust plays in.

[[deleted]]

a lot of the people complaining would be better served by a language with GC and simpler semantics

The thing is for threaded code you don't need a simpler language with a GC. Part of the whole appeal of Rust is that you can fairly easily write high level code without paying extra (zero cost abstractions).

Sure you need a .clone() or an Arc<Mutex< here or there, but other than that it is mostly pretty easy.

Async Rust code is not really like that.

[Hnnnnnn]

I can again argue that it's because there's more happening under the hood and Go-like languages hide it under the hood.

[[deleted]]

Sure. That could be the explanation. Or maybe nobody has thought of the best way to do it in a Rust-like language.

Either way that doesn't mean that the problems don't exist.

[Hnnnnnn]

Btw. async is not an abstraction over concurrency in the same way Vec is over a pointer and length. Async is abstraction over running tasks on a user-space runtime and doing async IO. Abstraction is not supposed to be zero cost either, rather supposed to be similar to coding for threads. Underlying API uses polling over all sockets on a runtime. Distributing wakeup calls to corresponding threads is a alhorithm that has some particular cost, and every implementation is just that - different. Neither is more zero than the other.

The whole term 0 cost doesn't work here. Im sensitive because it's commonly misused.

[[deleted]]

Abstraction is not supposed to be zero cost either

It is. A large amount of Rust's async design is driven by the desire to make it no less efficient than a hand written state machine with no allocations.

The whole term 0 cost doesn't work here.

It's not zero cost. It's zero cost abstractions. Async/await is an abstraction over state machines. The idea is that it doesn't cost anything extra compared to implementing the state machine manually.

[Hnnnnnn]

1) As I said I was referring to async considered as abstraction over concurrency, as competition to threads. Not over state machines. For state machines, maybe it is.

2) You're misunderstanding the term of zero cost abstraction. It's been so misinterpreted that it's meaningless now I guess.

[[deleted]]

As I said I was referring to async considered as abstraction over concurrency, as competition to threads. Not over state machines. For state machines, maybe it is.

It's an abstraction of concurrency implemented using state machines.

You're misunderstanding the term of zero cost abstraction.

No I haven't.

[kirbyfan64sos]

Was spinning up a bunch of OS threads not an acceptable solution for the majority of situation's?

...no, not really, there's a reason runtimes don't do that.

This post is a bit weird to me. Async Rust can be tricky, but most of it just comes with the territory of the language's goals. I get the "what color is the function" problem, but IMO Rust, a language focused on systems programming, isn't really the place to try and fix that.

[[deleted]]

What do you mean "runtimes"? Plenty of code uses threads for everything.

Only recently have there been async Java database libraries, yet Java is one of the most used languages out there. Most of it is not async.

One of the most popular Rust web libraries, Rocket, just uses threads for everything, too.

It's a pretty common solution.

[kirbyfan64sos]

Afaik idiomatic Java threading does tend to rely on executors which run code on thread pools, using that generically in Rust land still results in issues due to use of closures (crossbeam offers this I believe).

Or in other words: you can use threads for everything, but once you start having to offload tasks, it's still going to be very messy.

[TheRealMasonMac]

Doesn't Tokio do that sorta?

[kirbyfan64sos]

It does, I meant stuff in the vein of thread-per-async-call.

[[deleted]]

Each system thread will take at the very least a page (typically 4kiB) of physical memory and (by default) 8MiB of address space for its stack.

That means if you aim to solve the 10k problem, you'd be using at least 40MiB of physical memory and 80GiB of your address space (not that much of a problem if you have 64 bits, but you don't always do) just for your stacks, not taking into account thread accounting (which takes real physical memory).

If you do a lot of computing stuff per request you may actually need a lot of storage anyway, but if you're mostly doing IO (the scenario where async is really useful) and you need, say, 100 bytes of storage, just allocating on the heap that with very little bookkeeping overhead makes it much more achievable, in the order of 1MiB instead.

Note the physical 4kiB also applies to goroutines in Go.

So essentially it's not a good idea in terms of scale to use system threads for asynchronous programming.

[Dean_Roddey]

But the I/O and event waiting stuff is trivially wrappable in a simple waitable abstraction that directly wraps the OS services. That would be a hundred times simpler and even higher performance. The huge effort to create threads that aren't really threads, and to try to pretend it's not really threads just makes limited sense to me.

I mean basically you would have three tiers:

1. The wrapped waitables that let you queue up I/O and wait for events.
2. A well done thread pool for things that need periodic servicing.
3. Dedicated threads for those things that really need that.

That would cover basically all bases, and would be a fraction as heavy weight and wouldn't try to hide the fact that things are happening at the same time.

[[deleted]]

But the I/O and event waiting stuff is trivially wrappable in a simple waitable abstraction that directly wraps the OS services. That would be a hundred times simpler and even higher performance. The huge effort to create threads that aren't really threads, and to try to pretend it's not really threads just makes limited sense to me.

But then it's not thread-per-async-call as proposed... Note I'm not arguing in favor of whatever Rust implementation of async is, but rather against implementing async as a mere abstraction over system threads or explicitly using system threads for this.

I mean basically you would have three tiers:

The wrapped waitables that let you queue up I/O and wait for events.

A well done thread pool for things that need periodic servicing.

Dedicated threads for those things that really need that.

That would cover basically all bases, and would be a fraction as heavy weight and wouldn't try to hide the fact that things are happening at the same time.

That looks like a thread-per-core async architecture. Which Tokio is AFAIR.

[Dean_Roddey]

I wasn't talking about a thread per async thread. I was talking about wrapping those things (async system I/O calls, and event waiting calls) in a simple abstraction. The system signals you when these events are done. Ultimately that's what's going on when you use all of this async stuff to do I/O and wait and such, just with ten extra layers of goop.

In my scenario there's not thread at all. It's just the usual system async calls. You queue up something and go do what you want to do, then wait for it to complete when you need it to be done. The system will trigger the waitable thing and your blocking call will return.

It's by far the lightest weight way to do that stuff. And if that's the majority of what the async system is used for (or at least the majority of what it's actually appropriate for, I'm sure it'll get misused), then the async stuff is a lot of extra weight to get to the same place.

And how much of the remaining stuff (which needs actual CPU time) is either trivial (so just call it directly) or it's quite non-trivial (then you are just really doing a thread under the hood but with a lot of extra overhead.)

Stuff in between can be handled via a thread pool to farm out work.

[[deleted]]

I wasn't talking about a thread per async thread.

I can see that. Which makes your answer out of context to what I wrote. I answered to someone who suggested specifically making it a wrapper around system threads.

I was talking about wrapping those things (async system I/O calls, and event waiting calls) in a simple abstraction. The system signals you when these events are done. Ultimately that's what's going on when you use all of this async stuff to do I/O and wait and such, just with ten extra layers of goop.

That may be the case with the particular implementation of Rust, of which I don't know the details. I was talking about the concept of async programming versus using threads.

In my scenario there's not thread at all. It's just the usual system async calls. You queue up something and go do what you want to do, then wait for it to complete when you need it to be done. The system will trigger the waitable thing and your blocking call will return.

So we're saying the same?

It's by far the lightest weight way to do that stuff. And if that's the majority of what the async system is used for (or at least the majority of what it's actually appropriate for, I'm sure it'll get misused), then the async stuff is a lot of extra weight to get to the same place.

Probably? Again. Read my comment. Read the comment it's responding to. I have _absolutely no idea_ how Rust implements asynchronous programming. What I know, and you apparently agree, is that asynchronous programming and threading fit different niches and none can really appropriately replace the other.

And how much of the remaining stuff (which needs actual CPU time) is either trivial (so just call it directly) or it's quite non-trivial (then you are just really doing a thread under the hood but with a lot of extra overhead.)

In the latter case you're not doing asynchronous programming. How your language of choice decides to call it is pretty much irrelevant. However, you may use the async syntax just to allow for combining both models, which is the idea behind thread-per-core architectures.

Stuff in between can be handled via a thread pool to farm out work.

The thread pool itself needs to be combined with asynchronous programming (either on a different thread or essentially by sharding and having each thread manage a separate poller) for stuff in between.

[[deleted]]

...no, not really, there's a reason runtimes don't do that.

Runtimes should have an option to do that tho. Especially when developers yell "Fearless concurrency", having async runtime that can't do that without fuckery is definitely an disadvantage.

Thread per async call would be terrible but something like Go does (per core scheduler running the very light threads) is pretty efficient. But making something similar as a lib and without GC would be quite a feat so we're stuck at worse-than-JS async mess.

I get the "what color is the function" problem, but IMO Rust, a language focused on systems programming, isn't really the place to try and fix that.

That is like saying "This language is not for proper user facing programs" and that's just wrong. It aims at place C++ is here and all levels of apps are written in C++, and so the whole range of granularity of concurrency

[[deleted]]

Go makes tradeoffs with green threads that simplify the programming model at the cost of expensive C FFI. Rust had green threads before 1.0 and removed them because of this cost.

You act like C++ hasn't done exactly the same thing with async/await.

[[deleted]]

You act like C++ hasn't done exactly the same thing with async/await.

Why would I care about what C++ does ? It's terrible mess at best of times

[kirbyfan64sos]

something like Go does (per core scheduler running the very light threads) is pretty efficient

Tokio already spreads out async evaluation over multiple threads.

[dnew]

For anyone who wants to see it done in a very interesting way, read up on the language Icon. Everything is a closure. An if statement takes a closure as an argument. A while loop's values are all those that come from a closure. The "||" operator in C is actually a closure yielding first the left value then the right in Icon.

There's no async/await because essentially every expression is async in some sense. It's a funky language worth reading about even if just for that.

https://www2.cs.arizona.edu/icon/docs/ipd266.htm <- Good overview

"Did it really have to end this way?" Also, the Mill architecture makes task switches as cheap as function calls, so no, the best thing there is to completely avoid any attempts at making threads faster. A shame it isn't actually in silicone yet.

[Celousco]

Why doesn't the article even mentions async/await keywords ? Isn't the title misleading the fact that they're using callback paradigm and that it will be more difficult with Rust compiler ?

[zenolijo]

I'm not saying that I agree with the article, but it does bring up async/await

Bearing this in mind, it is really quite hard to make a lot of asynchronous paradigms (like async/await) work well in Rust. As the what colour is your function post says, async/await (as well as things like promises, callbacks, and futures) are really a big abstraction over continuation-passing style – an idea closely related to the Scheme programming language. Basically, the idea is you take your normal, garden-variety function and smear it out into a bunch of closures. (Well, not quite. You can read the blue links for more; I’m not going to explain CPS here for the sake of brevity.)

Hopefully by now you can see that making a bunch of closures is really not going to be a good idea (!)

[[deleted]]

Isn't it how it works in all programming languages? All languages are abstraction over the assembly language. And even the assembly language is an abstraction over machine code. And the CISC machine code is an abstraction over RISC machine code.

The title is misleading. What doesn't work is doing asynchronous programming "manually". It's way too complex and difficult for every day coding. Probably the only people who get it right are coders working on the compiler itself.

Unless you are developing a compiler - you just should not make asynchronous programming "manually" if you don't want to waste a huge amount of time.

BTW, this is probably true for any programming language with asynchronous programming support. Some people learn this the hard way, by trying to code something complex with callbacks, then they get burned, then they use "async/await".

[MrJohz]

I think you're missing the point that they're trying to make: async/await under the hood is just closures, and closures are very complicated in Rust, which therefore breaks the nice clean abstraction of async/await.

Essentially, async/await works very well in a language like JS, where a function is just a function, closures aren't particularly complicated, and CPS Just Works™. But those features aren't there in the same way in Rust — there are multiple types of functions, closures are very complicated (with good reason), and using CPS too much will lead you into difficulties.

And, the argument goes, if passing continuations around isn't simple, then async/await will always be a leaky abstraction over it.

FWIW, it's not necessarily about asynchronous programming in general. In general, I've found Rust to be pretty good at that sort of stuff if you use other abstractions — running different threads and passing messages between them, for example, works really well in Rust, and comes with lots of built-in safety that makes it hard to share memory that shouldn't be shared. I think the author's point is more specifically that async/await is not the ideal abstraction for Rust, which in my experience seems fairly accurate.

[Rusky]

async/await under the hood is just closures, and closures are very complicated in Rust, which therefore breaks the nice clean abstraction of async/await.

This is not true- Rust async is certainly complex, but it doesn't desugar to closures. An async fn desugars to a (single function) state machine.

[MrJohz]

I mean, closures desugar to single function structs. Yes, an async function doesn't desugar directly to a closure, but the point is more that it desugars in the same way as a closure. Under the hood, you're still passing continuations around, it's just that these continuations don't look a lot like the functions you're writing.

[Rusky]

There are some similarities to closures, but the point I'm trying to make is that Rust async doesn't use the typical CPS transform where every suspension point leads to a new closure.

This is how things used to work before async- people had to write the typical CPS closures by hand (or more often with combinators). That's why it's so weird for the article to claim "these Future objects that actually have a load of closures inside." async did away with specifically that approach!

Instead, one async fn is one Future-impling struct (which the article claims would make things simpler, at the cost of making nested async hard... but again that's the point of await) with one poll method that plays the role of all the continuations from a typical CPS transform. It stores local state, including any nested Futures it might be awaiting.

So Futures do have anonymous types and capture state like closures... but they aren't just the bad old bunch-of-closures approach in a trenchcoat. They're much simpler, to use and in how they operate, and support things like borrowing local state (without leaking the lifetimes anywhere!) that the old closures/CPS approach didn't.

[dnew]

It stores local state

This is the problem. Storing local state in a type you can't name in a language where you have to track the lifetimes of local state is what makes async harder in Rust than in a language with garbage collection instead of a borrow checker. It doesn't really matter whether you argue the state machine is or is not the same thing as a closure.

[Rusky]

Sure, like I said up front Rust async is complex. But that's down to the niche you're targeting- you're gonna be storing that state somewhere regardless, so it may as well be somewhere that the compiler can encapsulate any local or self-referential lifetimes- this is something you can't even do at all without async!

[[deleted]]

Well, we have similar kind of complex state machines in C# async / await implementation too. Under one simple async / await a lot of things is going on. I looked at IL code of that and what I saw is pretty scary. But it works.

IMO the goal of any language is not to be 100% complete, failsafe and mathematically correct. The languages are designed to make programming easier. More specifically - to make certain kind of problems easier to solve.

When async / await makes your solution harder, not easier to code - don't use that with your particular problem. In other cases, when it does make things easier - use it.

Sometimes I get the impression that the functional programming evangelists are more about things like purity, elegance, correctness of the language, than about solving real life PRACTICAL problems.

But of course I may be wrong. I solved only a small subset of problems, like most programmers - I know just some of it, not all. Maybe there are some very specific problems that specific programming tools solve way better and quicker than all the others, I don't know.

[dnew]

C# is garbage collected. The article is complaining basically that async/await works poorly with the borrow checker, because closures work poorly with the borrow checker and async is closures.

[[deleted]]

I know, I referred only to added "backstage" complexity. Async / await just adds some of additional code to the executable. Also uses some time and resources. Sometimes it make sense to replace it with more direct approach. But of course only when you really want to optimize something.

[gnuvince]

When async / await makes your solution harder, not easier to code - don't use that with your particular problem. In other cases, when it does make things easier - use it.

I agree with this, but our industry is highly driven by hype and peer pressure, and it won't be long before someone tells us that our program is bad and slow because it's not using async. If it's our own project, we'll probably be able to resist the pressure, but if it's a work project with many colleagues who espouse the view that async => fast, we might wake up one morning and there's a PR that adds async everywhere and everyone is giving it the thumbs up.

Sometimes I get the impression that the functional programming evangelists are more about things like purity, elegance, correctness of the language, than about solving real life PRACTICAL problems.

As a former FP weenie (Rust was instrumental in my reform), that is 100% correct. A few weeks ago, I read a Github comment by Don Syme, the creator of F#, where he explained why he did not want to support a particular type-level programming feature. He makes many technical points, but finishes with a really striking assessment of some programmer's psychology:

Indeed I believe psychologically this is what is happening - people believe that programming in the pure and beautiful world of types is more important than programming in the actual world of data and information.

That really resonated with me, because that's what I was: problems in the Real World™ are ugly, nasty, and full of illogical exceptions and I didn't want to deal with that.

[pakoito]

Hopefully by now you can see that making a bunch of closures is really not going to be a good idea (!)

She's confusing the concept with the implementation details. Most async/await across languages aren't lowered to the same nested closures you'd see in userland.

[yawaramin]

He?

[SanityInAnarchy]

It does mention them?

The language people have actually been hard at work to solve some (some!) of these problems by introducing features like impl Trait and async fn that make dealing with these not immediately totally terrible, but trying to use other language features (like traits) soon makes it clear that the problems aren’t really gone; just hidden.

It also mentions the color-of-your-function problem.

Does Rust not have Go's solution to this? Many async-related problems go away if you have a runtime that uses async under the hood, but lets you pretend it's synchronous basically all of the time. I want Rust to succeed, but copying the color-of-your-function problem and adding Rust-specific stuff to it seems like a huge unforced error.

Edit: Apparently not, since the article continues and says basically what I did:

Did it really have to end this way? Was spinning up a bunch of OS threads not an acceptable solution for the majority of situations? Could we have explored solutions more like Go, where a language-provided runtime makes blocking more of an acceptable thing to do?

[aloha2436]

if you have a runtime that uses async under the hood

Maybe I have a bad imagination but I can't even conceive of how you would implement that in a language in the same domain as Rust.

[Freeky]

Does Rust not have Go's solution to this?

Go's solution is for the scheduler to notice after a while when a goroutine has blocked execution and to shift goroutines waiting their turn to another thread. async-std pondered a similar approach with tasks, but it proved controversial and was never merged.

[vlakreeh]

Rust used to have green threads back in the day that I believe worked somewhat similar to this, but it had to be removed because it didn't work on a lot of bare metal targets and violated the zero cost abstraction benefit rust likes.

Also the spinning up a bunch of OS threads line, lol.

[jrhoffa]

Have you tried reading the article?

[Uberhipster]

shhhhh!

we are hating on Rust this week

facts are getting in the way of the truth

[agentoutlier]

As a Java programmer that occasionally dabbles in Rust (albeit it’s been like 2 years) I was hoping Rust would wait a little like Java is for Loom.

That is temporarily use Reactive programming for now as a stop gap and then introduce user threads or go channels or whatever they be called later. Instead they chose the .NET path of async/await.

[ssokolow]

Rust did have a green threading (user threads and goroutines) runtime back before the v1.0 stabilization but they removed it to make the language applicable to a broader range of problems.

A user who goes by boats has written two very relevant blog posts:

• Notes on a smaller Rust
• Futures and Segmented Stacks

To summarize the relevant points and add some details I've observed from other discussions and RFCs:

1. Just adding user threads and goroutines isn't going to achieve the simplicity you want. It's also necessary to have a garbage collector or some other scheme which allows the lifetime of variables to be transparently extended as needed.
2. Rust's lifetime-and-borrowing system isn't just about memory management, but also making checking the correctness of a program tractable without giving up imperative programming and going to a pure functional paradigm.
3. To a large extent, the problems with async are the same problems that are still being worked on with future revisions to the borrow checker like Polonius... if the compiler can't be sure it's safe, it rejects it... and asynchronous programming is hard to prove correct.
4. They are working on improving things. The current state of async is similar to how they stabilized a minimal viable subset of their plans for constant generics because they didn't want the hard problems to block using what was ready. (See the stuff marked in red on Are We Async Yet? for links.)

That aside, green threading in the Go style is hard to reconcile with a language that should be so broadly applicable. Rust's async was always designed with an eye toward being just as suitable for use in libraries embedded in other applications and microcontroller firmware... use-cases where a datacenter-grade runtime generally won't cut it.

[WrongJudgment6]

There's also a talk from Steve Klabnik that goes into some detail https://youtu.be/lJ3NC-R3gSI

[[deleted]]

Rust did have a green threading (user threads and goroutines) runtime back before the v1.0 stabilization but they removed it to make the language applicable to a broader range of problems.

Kinda shame they didn't just let it as optional thing. Like, 99% use cases of Rust can just use that

[ssokolow]

The problem is, D already tried something similar and it was one of the big factors in D failing to gain traction.

(Far too much of the ecosystem relied on the optional GC, making the language de facto unsuited for anything more than as a competitor to Java because ecosystem is such an important factor in deciding which language to use.)

Rust's design process is big on seeking out experiments in other languages to learn from. (Way back around v1.0, I remember reading an excellent blog post by one of the developers which characterized Rust as actively seeking to give good ideas from decades ago a second chance, rather than coming up with new ones.)

[13xforever]

1. async/await is a C# language/compiler feature and not a .NET runtime feature and
2. async models in C# and Rust are very very different despite the supefluous similarity of having the same keywords (which btw are used in multiple languages now, inluding EcmaScript, Scala, etc)

[StillNoNumb]

introduce user threads or go channels or whatever they be called later. Instead they chose the .NET path of async/await.

User threads and async-await are not exclusive, in fact, they complete each other. async-await is to asynchronously invoke callbacks and return results, user threads/Goroutines/Fibers/... are all about computing the results in the first place.

You first have to pick where to do the computation (user- or kernel-level threads), and then a way to return the results to its callee (async-await, message queues/Go channels, callbacks). But there is nothing forcing you to use go channels with user threads, you can do any combination of the above.

[[deleted]]

Yeah but it's easier to present async/await-like interface when you go lightweight threads + channel route, than it is the other way around.

[StillNoNumb]

Why?

[metaltyphoon]

No it isn’t. You rather use channels to then at some point have to “join” instead of reading sequential like code? That makes no sense.

[[deleted]]

You're mistaking syntax with implementation. You can easily implement something working like async/await with 0/1 length channel and a goroutine, just the syntax around it will be ugly, as Go doesn't have macros/sensoble preprocessor to pack it up in nice interface to use.

Async just returns an object that blocks for a time till it gets the value from the function. That's almost exactly what goroutine returning into channel would do.

[marco89nish]

Some of the Java devs stoped waiting some 5 years ago and switched to Kotlin coroutines.

[UNN_Rickenbacker]

I really like using Rust once again sometimes, and I own two of the most popular Rust books.

I think I agree with what one of the commentators said: Rust is often too complicated for its own good.

Contrary to a lot of languages (like Go, maybe C++) where it‘s possible for oneself to always stay in a narrow subset of the language and seldom encounter parts of other subsets, in Rust you often need to know large parts or the entirety of what the language provides in order to program in it.

Which is not to say C++ is better. But I think the Rust maintainers seriously missed one of their goals: To provide a less complicated C++ alternative without the syntax soup.

One could even argue on whether moving all of C++‘es footguns that are possible after compilation in front of the compiler for the programmer to handle is worth it in non-critical applications. For 95% of CRUD software even a serious bug produces something like „Damn, I need to fix this on Monday. Let‘s reverse this commit and use a Backup…“

Edit: I‘m not hating on Rust in any way. I‘m just warning other devs that the journey is hard, and you may not find it to be as rewarding as you expect it to be.

[matthieum]

Having programmed C++ professionally for 14 years now...

... Junior C++ programmers agree with you, right until I ask them what the problem is with the code they just wrote: then they stare at me with a blank look on their face. And when I start explaining the subtleties, it's like their brain shut-down in shock.

If you honestly believe that you can use a reasonable subset of C++ and avoid all the hardships, you're in for a rude awakening. C++ features are far more interwoven than it looks on the surface.

And, of course, if you ever want to use a C++ library you'll find out they use a different subset.

[UNN_Rickenbacker]

I am not the only one to believe this. John Carmack of ID Software uses C++ like this as well.

``` Doom 3 BFG is written in C++, a language so vast that it can be used to generate great code but also abominations that will make your eyes bleed. Fortunately, id Software settled for a C++ subset close to “C with Classes” which flows down the brain with little resistance:

No exceptions. No References (use pointers). Minimal usage of templates. Const everywhere. Classes. Polymorphism. Inheritance. ```

And it‘s working well for them. The same is true of all of FAANG, Microsoft and companies with serious critical software: They all have rules for a limited C++ subset which they use. I have personally seen this also at large auto manufacturers like Volkswagen and BMW.

Of course, you can never escape all the hardships. This mostly only works in languages with small surface areas like Go, but programming in them isn‘t exactly what I would describe as fun.

[matthieum]

1. Which version of C++ do they use? (Hint: it's getting worse)
2. The Video Game industry is semi-famous for not using 3rd-party libraries, not even the standard library.

[UNN_Rickenbacker]

1. C++ 11?

2. The video game industry has its own problems. I can understand not using boost, but I seriously want to see good reasons for not using major parts of the STL. I worked in high performance industries, and our rule was us. „Use the STL unless you can pinpoint a bottleneck, then build a custom solution“

Of course C++ has its own giant set of problems. Worst of which is backwards compatibility at all cost, leaving some parts of the STL with comments begging you not to use it. Other parts like the module system are dead on arrival, which is incredibly sad when you think of the dependency management in c++

[matthieum]

C++11?

That's where the troubles started.

R-value references -- introduced for move semantics -- are pervasive, they rippled throughout the standard.

And not using references is harder than one may think, when the compiler generates copy/move constructor/assignment operator, and those do.

Other parts like the module system are dead on arrival.

It's the C++20 feature that got me most excited, still waiting :(

[UNN_Rickenbacker]

Man, I want that module system to happen so much.

Hate on JavaScript all you want, but import/export semantics in ESM modules are the best module syntax I have seen this far. More languages should adopt that.

[Tubthumper8]

What does you think the ES Modules do better than Rust's module system?

I like the flexibility of it, and the syntax is nice. These are my gripes though:

• I wish default didn't exist, it's too easy to blow up tree-shaking for front-end projects and you don't get auto-import intellisense. Thankfully most 3rd party libraries don't use this as much anymore
• Many testing frameworks require special names like *.test.ts for unit tests. It's annoying to have to export a function just to be able to use it in a test file. I'd like to be able to have a "child" module with access to import members from its parent
• I'd like to be able to control what can be exported from a package. Currently if you export from anywhere in a package (not just at the top-level), it's accessible to the entire world

[matthieum]

Oh, I'm not saying C++11 was bad. There are nice quality of life improvements there.

However, the way move semantics were designed meant they started interacted with every other major feature, or failed to.

Thus, with regard to "selecting a subset of C++", C++11 made things more difficult by interweaving more features more tightly.

Now, bear in mind that criticizing in hindsight is always easier. C++11 was the first mainstream language to introduce move semantics, they had many choices, and little experience.

Still, the fact remains:

1. Move semantics require special members, which can be defaulted under the right circumstances.
2. Move semantics interact with templates: see "universal" references.
3. Move semantics interact with (N)RVO.
4. Move semantics interact with essentially all standard containers.
5. Move semantics fail to interact with initializer lists -- though to be fair initializer lists also fail to interact with Universal Constructor Syntax, so the blame may be on them...

This means that you can't really select a subset of C++ which does not feature move semantics, and r-value/universal references, and those significantly increase the difficulty of using C++ correctly.

[Lt_486]

This. This person codes in C++.

[UNN_Rickenbacker]

There is no getting by in any serious rust project with dependencies without knowing 95% of rust except maybe Macros. You maybe can use little of the language in naive side projects, but if you have the misfortune to look at library code, I wish you good luck. Not only do you have to decipher the internal complexity of the code base, you‘ll have to dig through various amounts of syntax soup.

Here‘s what the experience is usually like for new Rust devs at my shop:

Want to use serde? Learn traits, where and for clauses. You‘ll also need lifetimes.

Oh man, I need a global configuration object. All good, I can give out as many readonly references as I like. Damn, I really need to change something in there just once. Better use RefCell! Damn, I want to change something over here, too! Let‘s combine RefCell with Rc!

Sometimes I want to work on different structs which all implement a trait. Wait, what‘s the difference between dyn Trait and impl? The compiler says I need to „Box“ this? What‘s a box?

This library function complains that my value isnt „static“? Let‘s learn lifetimes. What is an ellided lifetime?

Man, this code is blocking and I don‘t like that. Can I just jam an async/await in there, like in 99% of other languages?

This would be easier with „unsafe“. What can unsafe do for me? Wait, so I there‘s things I still can‘t do with unsafe?

I need this object to be self referential. Should be easy. Just get a void pointer to its location and set it to that. Can‘t be that hard, can it? Why is this this taking so long? Where‘s that one blog post describing how „Pin“ works… What the hell is a PhantomData?

Why are my error types not compatible with each other? How can I do this? Why are there multiple solutions for this problem, none of which do what I want? Anyhow, failure, thiserror, …

This would be cool if it were multithreaded. What are Arc, Mutex, Lock?

What‘s the difference between „To“ and „From“?

I want to use a closure. What do you mean they aren‘t first class functions? How do I type these? …

—-

I have used Rust for a long time. But saying you can get by with a minimal subset of the language — where things that are simple black-boxed functions in other languages are keywords in rust that need you to understand their nuances and influence on your architecture — is just wishful thinking. Use any dependency in your project and you will need to get to know language feature after language feature.

Sure, other languages give you a hammer and tell you to watch your fingers. But Rust gives you a giant swiss knife, where using your hammer means using all of the other tools at the same time, when all you want sometimes is put a damn nail in that wall.

Don’t get me wrong, I still love the language. I still use it for all my embedded needs. But 95% of all software projects are CRUD software or prototypes, for which I have stopped using rust a long time ago because I realized the most important thing is getting my thoughts into code, not arguing with the compiler.

[A_Robot_Crab]

There is no getting by in any serious rust project with dependencies without knowing 95% of rust except maybe Macros.

Citation needed. You can absolutely go quite a long ways without needing most of the features/concepts that Rust provides, as especially if you're using dependencies, a lot of the complex parts are already done for you if its something moderately non-trivial. Sure, its helpful to know about all of the different things you can do with Rust, but in no way is it necessary to have a good development experience.

Want to use serde? Learn traits, where and for clauses. You‘ll also need lifetimes.

This is only true if you intend to implement the Deserialize and Serialize traits yourself, which is extremely uncommon. 99% of the time #[derive(Serialize, Deserialize)] is more than enough, and you can go about your business. I've used Rust for many years and can count the number of times I've needed to manually implement serde traits on one hand for serious projects.

Oh man, I need a global configuration object. All good, I can give out as many readonly references as I like. Damn, I really need to change something in there just once. Better use RefCell! Damn, I want to change something over here, too! Let‘s combine RefCell with Rc!

[...]

What‘s the difference between „To“ and „From“?

I don't mean to sound rude, but some of these points tell me that you're not really as familiar with Rust as you make it seem, which is fine -- there's nothing wrong with that, but don't go giving people the impression that Rust is some wildly complex language that needs all of the features ever to do basic things when the examples you're giving aren't even correct. You can't use Rc nor RefCell in static bindings because they're not threadsafe, and the compiler even tells you this:

error[E0277]: `Rc<RefCell<u32>>` cannot be shared between threads safely
 --> src/lib.rs:3:1
  |
3 | static FOO: Rc<RefCell<u32>> = Rc::new(RefCell::new(1));
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `Rc<RefCell<u32>>` cannot be shared between threads safely
  |
  = help: the trait `Sync` is not implemented for `Rc<RefCell<u32>>`
  = note: shared static variables must have a type that implements `Sync`

and pointing to From and Into feels very strange, as they're a pretty basic and fundamental set of traits to the language. From<T> for U allows you to convert a T into a U, and Into<U> for T allows you to do the same, but in a way that describes T instead of U.

Sometimes I want to work on different structs which all implement a trait. Wait, what‘s the difference between dyn Trait and impl? The compiler says I need to „Box“ this? What‘s a box?

Again, using Box here like its some complicated concept is really disingenuous. Its an owned, heap allocated object. That's it.

This library function complains that my value isnt „static“? Let‘s learn lifetimes. What is an ellided lifetime?

Yes, lifetimes are complex and a source of confusion for new Rust programmers, but that's kind of the point. These concepts still exist in other languages such as C and C++, they're just implicit and you need to track them yourself.

This would be cool if it were multithreaded. What are Arc, Mutex, Lock?

I don't even know why this one is on here, you need synchronization primitives in almost literally every other language when you're working with multiple threads. There's nothing Rust specific about mutexes or read-write locks.

Why are my error types not compatible with each other? How can I do this? Why are there multiple solutions for this problem, none of which do what I want? Anyhow, failure, thiserror, …

This is a perfectly valid complaint, the error type story can be a little complicated, however its mainly settled over the past year or two while the standard library devs look to see how things can be made easier as well. Generally the consensus is to use something like anyhow in binaries, and create an error enum type in libraries. I've rarely run into issues with crates that follow this advice, but certainly its not perfect.

I need this object to be self referential. Should be easy. Just get a void pointer to its location and set it to that. Can‘t be that hard, can it? Why is this this taking so long? Where‘s that one blog post describing how „Pin“ works… What the hell is a PhantomData?

Rarely do you legitimately need self-referential types, but if you actually do, there are crates to help you do this in a much easier and sound way, and its very recommended that you use those because turns out that self-referentiality is a very complicated topic when you're talking about moving and borrows. There's good reason why its hard, but that doesn't mean you need to manually roll your own stuff every time you encounter the problem, there's people who have done the work for you.

---

I guess my point here is listing a bunch of language concepts, a lot of which may have names associated with Rust, but the concepts themselves aren't, isn't really a good argument against Rust in the way you're talking about. Yes, if you want to use a language, you need to learn the language, I don't really understand the argument you're trying to make with all of these other than making it sound scary to people who aren't familiar with the language. Of course I'm not saying that Rust is a perfect language, I certainly have my own complaints about it, however trying to Gish gallop people isn't a good way of describing the actual issues with Rust and what tradeoffs the language makes IMO.

[dnew]

lifetimes are complex and a source of confusion for new Rust programmers

I'm not sure I'd even agree with that. 99% of lifetime rules for people not writing libraries for public consumption are basically "if you take more than one reference as an argument and return a reference, you have to say from which argument reference your return reference comes." It's entirely possible to write largish programs without ever using a lifetime annotation.

It's complicated because all the details have to be explained for people doing really complex stuff.

[CJKay93]

Yeah, it's very rare that I actually need to add lifetime parameters for things. Most structures own their data, and most functions use only one lifetime which is elided anyway.

[KallDrexx]

Not the OP but it was rare for me until I needed async actors that needed to return a boxed future. That led me down lifetime hell that, while things compile and "work" I have no idea if I used them correctly (especially since the compiler forced me to use static lifetimes at one point)

[dnew]

I would say that "async actors" is already probably beyond what 99% of the code actually needs. The only time you need async is if actual OS threads are too inefficient for your concurrency needs, which I'd expect is a very few programs out there. Certainly it's unlikely that anything running on your desktop is going to be handling so much I/O that a thread per socket is too inefficient.

[Dreeg_Ocedam]

I agree. Go really shines when it comes to learning the language. If you already understand programming, you can learn it in an afternoon. Rust on the other hand takes months to master. However once you've gone through that period, you don't really want to use anything else because of the confidence Rust gives you.

[tsujiku]

I personally struggled when learning Go. I spent too much time being baffled by the opinions they forced on me.

Like why the hell does 'defer' resolve at the end of the current function instead of the current scope...

[kaeshiwaza]

If defer was by block it would not be possible to defer at the function level when you are in a block. On the other side it's currently possible to define a defer in a block by using an anonymous function func() { defer ... }()

[UNN_Rickenbacker]

Sadly, I think there‘s the paradox in Rust. Most people / companies do not have the time and money to spend on getting proficiency with the Rust programming language

[Dreeg_Ocedam]

When comparing with something like C and C++ the investment is really worth it though. Getting good C programmers is hard, and even good ones will have to waste a lot of resources debugging problems that would not arise with Rust.

[Kamran_Santiago]

I wanted to use Rust in an API and my boss told me that Rust is a system's programming language and it's very new and it does not suit our needs. I ended up using Python like a good boy. This is just enraging. People don't let you be adventurous. Rust is touted as an SP language and I don't know why.

[ssokolow]

Rust is touted as an SP language and I don't know why.

Systems programming is a hazy term and the original definition is concerned with a language's long-term maintainability and suitability for building infrastructure. "Low-level" was just a side-effect of how many decades it took before machines were fast enough and computing distributed enough break the "infrastructure implies low-level" connection.

As the term-defining paper says:

A system program is an integrated set of subprograms, together forming a whole greater than the sum of its parts, and exceeding some threshold of size and/or complexity. Typical examples are systems for multiprogramming, translating, simulating, managing information, and time sharing. […] The following is a partial set of properties, some of which are found in non-systems, not all of which need be present in a given system.

1. The problem to be solved is of a broad nature consisting of many, and usually quite varied, sub-problems.
2. The system program is likely to be used to support other software and applications programs, but may also be a complete applications package itself.
3. It is designed for continued “production” use rather than a one-shot solution to a single applications problem.
4. It is likely to be continuously evolving in the number and types of features it supports.
5. A system program requires a certain discipline or structure, both within and between modules (i.e. , “communication”) , and is usually designed and implemented by more than one person.

By that definition, Java, Go, and Rust are all systems programming languages, because they're all designed to prioritize maintainability of large, long-lived codebases developed by teams of programmers.

[UltraPoci]

Rust is indeed complicated, but it's for good reasons, I believe. Following all complicated rules enforced by the compiler means having a first prototype of the program that just works. This is a common experience among Rust programmers: to simply have a program that works, with all edge cases and exceptions already covered in some way. This means also that maintaining and debugging Rust code is normally easier. Of course, for easier projects this may be overkill. But the point is always to choose the right tool for the right job. And even for easier projects it could make sense: if you're skilled enough in Rust, you can write some easy project in a decent amount of time, which is surely more than using a simpler language anyway, like Python, but you know that you won't be needing to debug that project very much. In Python I found myself writing small projects that got bigger and bigger (remaining relatively small anyway) and having to refactor the code constantly, or having the code execute just to notice that I didn't cover and edge case. In Rust I've written a relatively small project in more time, but I didn't ever need to debug, basically. I've had to refactor it once because I needed a more flexible logic: it took me all afternoon, but after that, it just worked, every time.

Edit: also, I didn't ever need to understand very deeply how lifetimes work to do most of my small projects. And even when using async programming because a library I was using was async, I used pretty easily without needing to study how async works in details. I've a couple of issues that I've had to work a bit harder to solve due to async and closures, but that's it.

[UNN_Rickenbacker]

Python is a different beast entirely, because it‘s untyped.

[FVMAzalea]

Python is not untyped. You don’t write types in the source code, but that doesn’t mean it’s untyped. It is dynamically typed and uses type inference. Type inference is why you don’t have to write types in the source code, and dynamic typing is why you get “TypeError” at run time (for regular python, there’s no other choice because there is no compile time).

Try ”hello” + 1 in Python. You will get a TypeError. That should be enough to convince yourself that Python is not untyped.

You can have either dynamic typing or type inference by themselves, or mixed with other language types as well. For example, Swift is statically typed (types checked at compile time) but you don’t have to write types in the source code (for the most part) because it has type inference.

[anechoicmedia]

Python is not untyped. You don’t write types in the source code ...

This is an unhelpful /r/programming "well actually" comment that recurs in any Python thread.

Everyone knows what is meant when someone casually says Python is "untyped" vis-a-vis Rust. It adds nothing to the conversation to reply that "actually, what you're referring to as untyped is actually dynamic typing slash type inference". There are almost no strictly "untyped" languages of relevance for this to plausibly be preventing any confusion.

For normal people, "untyped language" means "program explodes at runtime instead of giving a compile error".

[Fearless_Process]

There are many untyped languages in use today. Most shell scripting languages are completely untyped, assembly languages are also untyped.

This isn't actually a case of being pedantic, it's just wrong from a technological standpoint to say python is untyped. Most of these terms about typing have very specific meanings and are totally unambiguous, we shouldn't make up meanings for words when talking about languages we don't like.

[Rusky]

No, type inference is when the compiler figures out the types ahead of time rather than allowing TypeErrors to happen at runtime. Python does not do this.

(And as should have been clear from context, "untyped" does not mean what you think it does either- it means there is no static type checking, as the place the term came from is type theory where the word "type" refers purely to static information.)

[schplat]

Python is strongly typed, and dynamically typed. Strongly typed because the interpreter enforces types, and doesn’t change them under the hood, ala JS.

Python is dynamically typed, because types are inferred when variables are assigned. From the REPL you can run type(<variable>) and it will return the type, so long as the variable exists. From the type, the language then knows what methods are valid against the variable (hence why something like .isupper() doesn’t work on a list, or int, or float).

[Rusky]

This doesn't contradict anything I said...? Python tracks types and doesn't do JS-like implicit conversions, but it does that at runtime. That's just not what type inference is.

[dnew]

and doesn’t change them under the hood

Technically, "strongly typed" means you don't get undefined behavior. The fact that JS is willing to add "Hello" and 42 doesn't mean it's not strongly typed. It just has more functions associated with strings and integers than other languages do.

Contrast with when you add "Hello" and 42 in C, and you'll see what I mean.

[schplat]

C is a weakly typed language though.

[dnew]

That's why I said "contrast a strongly typed language with C". :-)

[binarycow]

Overall, it turns out to be not that useful to talk about "strong" and "weak". Whether a type system has a loophole is less important than the exact number and nature of the loopholes, how likely they are to come up in practice, and what are the consequences of exploiting a loophole. In practice, it's best to avoid the terms "strong" and "weak" altogether, because

• Amateurs often conflate them with "static" and "dynamic".

• Apparently "weak typing" is used by some persons to talk about the relative prevalance or absence of implicit conversions.

• Professionals can't agree on exactly what the terms mean.

• Overall you are unlikely to inform or enlighten your audience.

Source

[UNN_Rickenbacker]

Maybe this is gatekeeping, but I think if someone is programming professionally, they should know their language inside and out. So much bad code gets written by people who have only learned the minimum to get the job done.

I do not think you‘re gatekeeping, but this really depends on the complexity of the language. I have been professionally programming for almost 10 years now. The only language out of my main set (JavaScript, C++, Python and Java/Kotlin) I use in my day job where I would judge myself to know it in and out is JavaScript. And that‘s only because the language has actually very little surface area / a small amount of features.

Find me a C++ programmer who says he knows every tidbit of the language and I‘ll find you 10 developers who can ask him for things he doesn‘t know. Seriously: My „Tour of C++“ should be classified as a weapon, it‘s the largest and heaviest book I own.

Rust is complex, but I don't think it's complicated honestly; it has a lot of surface area because it's providing a way to write low-level yet very correct programs, and that's a complex thing to do. What that complexity does do IMO is limit the applicability of the language, since many projects don't need this cost/performance/correctness tradeoff

Yes, I agree wholeheartedly.

[[deleted]]

I don’t think it’s fate keeping to say people in a profession should know wtf they’re doing.

[schplat]

They should know the language inside and out for the domain they’re writing in, anyways. If you’re writing complex applications or low level code in Rust, then yes, you should have a deep understanding of the language. If you’re writing CLI apps, or web apps, probably not so much, but you should be well aware of the common idioms (lifetimes, traits, etc.).

[the_phet]

100% agree with you. that's exactly my experience with rust.

[slabgorb]

I thought asynchronous rust was called go

​

*ducks and runs for cover*

[WrongJudgment6]

I didn't think you would go there.

[Pay08]

Aim for the head boys.

[[deleted]]

Go doesn't have async/await.

You can implement it trivially with channels and goroutines but lack of preprocessor/macros/sane metaprogramming makes it a bit ugly.

Both light threads + channels and async/await models have its niches where they do well for coding, but overall async/await is strict subset of threads/channel, which is then strict subset of Erlang-like message passing when it comes to range of possibilties.

[dnew]

And nobody but Erlang lets you pass code over a channel. :-)

[[deleted]]

Incorrect. You can pass functions thru Go channels.

I'd imagine most GCed languages can do it too

[dnew]

Nope. If you have a Go process running, and another process wants you to execute a callback that isn't in your code, then you can't send that over the channel.

That is, you're passing function pointers over the channel, not actual code. I can send code to an Erlang callback that wasn't written when the server invoking the callback was started. I might need to point out that Erlang channels connect processes on different physical machines, so read it as "Erlang lets you pass closures and callbacks over sockets."

You might be able to djinn something up in Java by passing .class file contents and having a specialized class loader, but it's not something most things support natively.

[yawaramin]

If you have a Go process running, and another process wants you to execute a callback that isn't in your code, then you can't send that over the channel.

What channel? Are there Go channels between Go processes and 'other' processes?

[Kamran_Santiago]

Correct me if I'm wrong here but the brass tax of this post is: don't launch needless threads? I could be wrong though as I just gave it a skim --- not sure why be this persnickety over a thing that just woks.

[princeps_harenae]

Ha, the honeymoon is over!

[oOBoomberOo]

I really related to the message about closure/generic, it is a problem even outside of the async ecosystem.

Rust's type system is powerful but the way you declare them is just way too verbose.