Comment by danpalmer | Hacker News Reader

Comment by danpalmer | Hacker News Reader

This just doesn't match with my experience of Swift. My experience is a language that is well designed, at times feeling too complex, but always justifying that complexity with correctness when I dig into the reasons. Most of the language is driven by an open process, to the point that language announcements at WWDC are only a recap of the last year of accepted enhancement proposals.

"A great language strangled by governance" – it's not clear to me that Swift is in a materially worse place than any of the 3 alternatives this post points to. Rust has had a lot of drama and botched their async/await, Python had 3, took a decade to recover, and has failed to address its terrible packaging over the last 2 decades, and the Kotlin process described sounds almost identical to the Swift process.

Was Swift entirely top-down controlled at the beginning, with a bunch of breaking changes? Yes, but it has very clearly graduated from its early development now with no forced breaking changes and an open proposal process that is clearly working. Has Swift hard-coded Apple framework exceptions? Maybe, but that has never gotten in the way of me using or understanding Swift code, so I'm not sure it affects me as a developer. Has Swift become a hugely complex compiler? Sure, but I'd rather have a complex compiler and a better developer experience, especially if Apple is paying for it.

I don't disagree with the facts here, this just doesn't resonate with me at all. I'm a very happy Swift user, would like to be using it a lot more, and enjoy the forward momentum in the ecosystem as Swift becomes in my mind one of the most advanced languages available.

Not to your main point, but I don’t think it’s fair to say Rust “botched” its async impl.

There are certain features it’s missing, but nothing about the design really prevents them from being added. And many have been in the past few years.

I’d point to the “leakpocalypse” as a more fundamental Rust flaw.

Having perpetually colored functions is a huge, fundamental annoyance with the Rust concurrency design.

What would be a good way to not have sync / async colors?

Explicit yield / resume, like Lua? Full-on CPS?

Go handles it quite nicely. It's not perfect, but it is nice. Every function is a coroutine. There is no such thing as a non-async fn in Go. But if you want explicit await-like concurrency, then you can explicitly wait on a message from a channel.

Every time I bring this up there are people who jump in with excuses for why Rust can't do something similar. But these are either (1) historical accidents in the sense of implementing goroutines would've broken existing code [fair], or (2) excuses. Go's approach is much harder to get right, and much more pervasive in the impact on the language. But when it's done well, it's really smooth to use.

I use Rust as my daily driver because I want the safety guarantees that Rust gives, and cargo is pretty nice. But every time I need to do something highly concurrent, I wish I was working in Go...

There is a good reason why Rust can't do it the Go way - Go's always-async concurrency requires a fairly heavy runtime. Rust is designed to be able to support systems that have no runtime at all, or a specialised one. (https://embassy.dev/ is an example of a specialised async runtime for running async Rust on microcontrollers).

Why wouldn't you be able to swap out the concurrency runtime for something else? Or not switch it off entirely when not needed (making the concurrency keyboards into syntax errors)?

You can, you can switch it off by declaring a normal non-async function.

It's almost as if there's two fundamentally different types of functions that people might want to declare, necessitating two function colors.

Go is a language that is primarily used for async programming, so the design of having everything async makes sense. Rust is a language that is primarily used for sync programming, async programming is catered for but it's not the focus of the language. So having everything be async doesn't make any sense at all.

> It's almost as if there's two fundamentally different types of functions that people might want to declare, necessitating two function colors.

Since any function can get indefinitely stuck in a system call, the main difference between "sync" and "async" isn't whether you can pause execution, it's who can pause execution. And the main downside to the more flexible option is that it requires extra overhead in how the stack gets allocated.

But why should the flexible/inflexible choice be made on a per-function basis? I feel like I'm manually annotating which functions will inline, except worse because certain combinations won't compile. Instead, how about having the compiler figure it out on a per-call basis?

Rust used to have a GC in the past, as well as green threads and a bigger runtime. All of this has been explicitly removed before Rust 1.0. The reasons are well documented in many pull requests and RFCs for the language.

The way the async feature works in Rust is that the asynchronous function is just a syntax sugar that gets desugared into a state machine struct during compilation. The way this state machine works is similar to how one could achieve async in a language like C. It's unfair to dismiss everything as excuses given that the fundamental aim of the language is different.

In Rust async functions are not really colored because again - the async function is just a syntax sugar for a struct you can create and use in a sync context. The colors analogy is only really applicable in a language like JavaScript, where there's no way to poll an async function in a sync context.

Here's the thing though: Rust could have every function be an async state machine, automatically. And then the compiler optimizes away that code when it isn't needed. It would be a big pain to implement, but it's doable, and it would deliver a developer experience much closer to Go's. There isn't a technical reason for why Rust couldn't do this.

FYI you can't poll an async result in a sync context in Rust, either.

> FYI you can't poll an async result in a sync context in Rust, either.

Sure you can. Async runtimes in Rust are written in Rust, that's exactly what they do.

> There isn't a technical reason for why Rust couldn't do this.

First, it would be a huge undertaking. That in itself is a huge time/resource burden.

Second, it would add overhead to any non-async function call. Because async introduces branching on every function invocation, it would make the resulting assembly even harder to understand. This strongly goes against the zero overhead/ zero cost abstraction idea of Rust.

By the same measure, Go could technically remove (almost) all GC, add some kind of borrowing mechanism and steal Rust's thunder.

Elixir/Erlang, Go, Java all do. Java is new to the game with “green threads”.

If you decide to go with the async/await model, why not just go all in and have every function be async/await always? Gets you concurrency support without Colored functions. Is there a language like this?

Go.

I haven’t used Go, but I am fairly certain it’s not really trying to do the same things as Rust. IIRC, calling C from Go isn’t zero cost. It also includes a much larger runtime than Rust.

Yes, calling C from Go has significant overhead for exactly this reason. It basically requires creating a stack and copying over all the current coroutine info into it. Depending on the application, this can be accelerated by maintaining a cache of stack objects to use, or by having a "noasync" mode of compilation with all the coroutine stuff turned off (making calling C zero cost again), or by having a producer-consumer channel to a noasync thread that gets stuff passed to it from coroutine land and calls out to C.

Generally speaking, applications tend to either (1) exist as low-level shims or embedded code that doesn't use coroutines, (2) be large Rust projects that don't call out to non-Rust stuff often (e.g. a web server), or (3) large performance-sensitive applications that call low-level APIs frequently (e.g. games). The above solutions handle all three of these cases.

What Rust chose instead was to optimize for a compilation mode which supports all three cases at once, with zero cost for FFI. This sounds nice, until you realize that what they traded off to get this was UX. Writing concurrency in Rust is lightyears better than C++, but it still sucks compared with Go or Erlang.

That sounds like a few different languages. And I think it’s fine to want a language like Rust that allows you to be less explicit about things. Based on what I’ve heard, you might just be looking for Gleam.

But I don’t think it would be the right move to make Rust something that it’s not, just so people don’t have to think about what a Future is or isn’t.

You never tried to await from within a synchronous function? There's stuff that you just can't do with Rust's approach to concurrency, that would be trivial if we allowed some limited cost abstractions (e.g. thunking the future in this case). Or just make all functions asynchronous but eliminate the state machine if it contains no yields.

The whole point of higher level abstractions is making it so that developers don't have to think about stuff. It's what I love about Rust: with the borrow checker, I know that if it compiles then I am not going to be accessing mutable or already freed state. The language and the compiler get more complicated so that I don't have to think about stuff.

Rust didn't go that way with concurrency. They instead opted to push that complexity (thinking about what a Future is or isn't) onto the developer. YOU have to think about "should this API call be async?" instead of letting the downstream user decide that.

> You never tried to await from within a synchronous function?

Whenever necessary I have been able to do this easily. Calling async code from a synchronous context is not an example of something which can’t be done in Rust today.

> Or just make all functions asynchronous but eliminate the state machine if it contains no yields.

The optimizer generally already cleans this up.

> The whole point of higher level abstractions is making it so that developers don't have to think about stuff. It's what I love about Rust: with the borrow checker, I know that if it compiles then I am not going to be accessing mutable or already freed state. The language and the compiler get more complicated so that I don't have to think about stuff.

The borrow checker is not “limited cost”. It is zero cost.

> Rust didn't go that way with concurrency. They instead opted to push that complexity (thinking about what a Future is or isn't) onto the developer. YOU have to think about "should this API call be async?" instead of letting the downstream user decide that.

There is no zero cost way of doing this.

The borrow checker is not "zero cost". That is a myth. It forces the use of non-zero overhead escape hatches (RefCell/Rc) almost every time when the code tries to do something nontrivial, that is, something actually worth doing.

The guarantees given to you by the borrow checker are zero cost.

Once you’ve exceeded its capabilities, you have the choice to either pay a runtime cost (use RefCell and friends) or deal with maintaining and validating unsafe code.

Even though I am not a big fan of its design, there are hardly any scenarios were Go doesn't fit other than cargo cult against automatic resource management languages.

To the point that even disliking Go, I might favour it over Rust, unless using any kind of automatic resource management is forbidden, and I don't feel like reaching out to C++ for whatever reason.

And Erlang, Java as well.

Go is the opposite, everything is synchronous. This works great with CSP to allow for concurrent workloads, but its functions/methods are not async. I mean language where every function/method call works like async/await. The idea is probably closer to Haskell and its lazy evaluation.

How so? It’s trivial to block on a Future or to call a function within a Future.

I could imagine another language where all “functions” are Futures, but I don’t think that would be the right move for Rust.

At the very least, that alternative language would probably have to provide a default executor. IMO, that’s a bit much for a language that aims to have a very minimal runtime.

As I mention in replies to sibling comments, Go works that way: every function is a Future, and there is no such thing as a non-async function. It works pretty well and is super easy to use and reason about, with no hard edges.

Yes, it would have to provide a default executor in the standard library. And it would have to have a noasync mode (analogous to nostd) for embedded applications that can't have asynchronous execution. These are hurdles, but not very large ones.

The ship has sailed though.

A great bit about Rust async is that it’s sufficiently flexible for use in embedded environments.

I would really not prefer a Rust that includes a more intrusive runtime. Especially given the API changes things like io-uring may require to exploit.

As it works now, I can nearly always predict what assembly I’ll see when I compile a Rust program. It’s predictable enough to work anywhere C does. I would hate to lose that.

The other comment implied it but I think it's worth pointing out that:

> embedded applications that can't have asynchronous execution

Is most definitely not the case.

They can't have the same type of async runtime that would be optimal for a web server or the likes (and I'm not sure all desktop applications and web servers are going to always benefit from the same runtime in the same way), but that's a point in favour of Rust's model imho

If you're interested this is an embedded async runtime that's expected to run in no-std and no-alloc environments

https://embassy.dev/

"embedded applications *that* can't have asynchronous execution"

not

"embedded applications can't have asynchronous execution"

there are embedded applications that are compiled with no concurrency runtime. I'm not saying all embedded applications work this way.

Yeah, I think I added a comma while reading by mistake so I thought the "that" was preceding the explanation of why you singled out embedded, my bad

The point about a runtime optimized to run bare metal on a single core probably being suboptimal on a desktop machine with 8 cores still stands though. (And the laptop one is possibly not going to work optimally on a server with hundreds of core either)

I'm still skeptical that such a thing exists. A concurrency runtime doesn't have to be much more than a queue of function calls. What kind of hardware can run normal code but can't do that?

Interrupt handlers, for example.

Depending on your implementation it is very possible to schedule interrupt handlers into a concurrent runtime. You'd have to be exceptionally careful about how it was designed with regards to, like, reentrancy, but Rust is quite good at encoding these kinds of things.

An interrupt handler could schedule an asynchronous task just fine. In a lot of situations that would be a very good way to handle things.

You shouldn't await in an interrupt handler, but there's a lot of things you shouldn't do in an interrupt handler. A rule like that doesn't mean you need a noasync mode. (And if you really wanted to use await there, you could make it work with priorities or with a separate task queue.)

No, the reason this doesn't work for Rust (and even more so Swift) is that they need to call code that is not annotated. In Go the runtime knows what blocks and what doesn't, and this lets it effectively manage its thread pool based on the state of every goroutine. If you call outside of your runtime, you lose guarantees about what that code might do: it could block indefinitely or deadlock some other code in your program. Solving this is a pretty hard problem, which is why the solutions these languages have designed are limited. (Again: Swift ships with its own runtime; there is a default "executor". It doesn't actually solve this problem for the reasons I described.)

> It works pretty well and is super easy to use and reason about, with no hard edges.

Oh,rly?

https://songlh.github.io/paper/go-study.pdf

Doing that in Rust can be a footgun if the synchronous code blocks for too long. You often want a separate threadpool for calling those functions. It works great in Swift, though!

Swift mitigates a lot of the function coloring pain: synchronous methods can conform to asynchronous protocol requirements, thanks to the compiler generating thunks (at least, I think that’s how it works)

A thunk wouldn't be zero-cost.

Of course. But the common case of calling a synchronous function from a Future is something trivial like a + b.

Isn’t this what spawn_blocking and block_in_place do?

The opposite, actually. Swift (Concurrency) doesn't really have a good way to do the kind of thing spawn_blocking does. (Though, some would argue that the very design of spawn_blocking is not good to begin with.)

Yes! In Swift there is no need to do this sort of differentiation, though, which is more ergonomic. Different trade-offs.

Swift has the same problem, FWIW.

That may be more fair. I guess a better way of putting it is that the async/await implementation was fraught with drama and that it did not really succeed in getting the whole community onboard and pulling in the same direction.

Python, for example, continues to have similar issues, whereas Node/JS definitely did stick the landing, and Swift arguably did too.

Yup, that’s an entirely fair characterization. One I probably should have understood from your initial comment :).

Yeah. I think "keyword" is less of an issue personally. At the end of the day, if we want to approach things like async / await and ownership, I would prefer "consume / borrow" than some particular symbols.

That has been said, I do worry that there are too much runtime stuff built into the language, and it doesn't seem there any desire to clean it up. Newer things like actors that people argues cannot be done as library brings runtime into the language. autograd is in the similar vein. Even automatic-reference-counting (a.k.a. classes) would be nice to move that out of core language.

The end result is that Swift is a huge project for people to maintain, in both the compiler land and the runtime land. I am happy that Apple is paying for it, but ...

I do find it quite unsatisfying the way the actor executor is somehow magically generated at compile time, without any way to build your own in Swift. It's also not obvious that actors are re-entrant until you stumble into it.

It's quite interesting the way the swift compiler gets around its own complexity by wrapping core functionality as llvm builtins whenever the engineers hit a wall. Is it an abstraction? Not really sure what to call it, but I'm finding it becomes a very leaky design after working in large Swift codebases.

Sure, there is always intentionality behind the decisions that get made, and not saying it its sloppy, it's not. However, every single language design decision feels one-off, and in 2024, the language is now made up of hundreds of little one-off decisions that somehow still work out okay.

Yeah. I guess that I misspoke a little bit. I am not even criticize actor (as in Go, there is a relatively "heavy" runtime to implement its green thread too). I was originally thinking about distributed actor proposal (and implementation) and forget to spell that out.

> It's also not obvious that actors are re-entrant until you stumble into it.

Yeah, this part is annoying. While understandable from runtime implementation perspective, it feels like a big mistake need to be corrected in the future.

> the language is now made up of hundreds of little one-off decisions that somehow still work out okay.

There are some fixes on these decisions, some times. For example, `some` / `any` fixed some associated type related weirdness that you need to workaround (this is a huge improvement for me at least).

But some other problems remains: the existence of existential type is not obvious at all and can cause issues. For example, a closure type is not existential, and cannot be extended. This is OK most of the time, but then UnboundedRange is defined as a closure: https://developer.apple.com/documentation/swift/unboundedran... so you cannot extend that easily (which would be ideal if you want to extend PartialRange / ClosedRange / UnboundedRange to do something like, return Python slice object?). I think this / or similar issue also made things like tuples to automatically conform to Equatable / Hashable protocol not easy to do, which is not big problem, but minor annoyance.

They actually allow you to opt out of ARC in Swift 6 by marking types as non-Copyable (~Copyable), along with “consume” and “borrowing” keywords. There are restrictions (i.e. their use in generics is limited), but it’s pretty great for optimizing hot loops.

Have you had much success adopting consume and borrow?

Once you need anything in the swift standard library, you can't use a non-copyable struct with it. The keywords are all in too, so either you write completely self-contained rust-like code that doesn't touch your other code, or you revert back to using the older copyable types.

I've tried many times to ease into using them, but I can never stick with them, and eventually revert.

I do really like the high-level design though and look forward to it evolving into something usable.

Nope. The ergonomics are really bad at the moment. I also had to revert any places I used them in API surface.

I haven’t had a use case yet where I could use them privately in the internal functioning of a type.

I thought borrowing could still be used with Copyable types, though

I agree, the number of keywords really doesn't get in may way day to day. You know what does get in the way? Lack of functionality.

I use Go in my day job and it's really quite frustrating to write much of the time because the compiler does so little for you. I regularly hit issues that would be checked for me in Swift, I regularly write type-unsafe code because the type-checker isn't sufficiently advanced, or I implement slow things myself because it's impossible to use a generic fast implementation, and I don't want a week long side-quest implementing an obscure data structure in my otherwise 2 day long feature.

In that way Go is much like C, and while it's trendy to hate on C++, there was a reason why C++ was created – C wasn't doing enough for people.

Reply on news.ycombinator.com