Let futures be futures (without.boats)

submitted 2 years ago by [email protected] to c/[email protected]

7 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[-] [email protected] 4 points 2 years ago

The bit about Rob Pike at the end is killer.

[-] [email protected] 1 points 1 year ago

What's the part about Rob Pike? I didn't see anything mentioned in the article.

[-] [email protected] 2 points 1 year ago

It doesn't mention him by name, but he's the "language designer of some renown" alluded to here:

If you were a language designer of some renown, you might convince a large and wealthy technology company to fund your work on a new language which isn’t so beholden to C runtime...

[-] [email protected] 1 points 1 year ago

Ah, thanks, makes sense. I largely skimmed the conclusion, so I guess I didn't make that connection.

I did think about Go throughout the article, since it basically uses "green" functions everywhere. I guess I got tripped up when they mentioned "effect handlers," which isn't a thing in Go AFAIK (then again, I'm not a language designer), unless it's used under the hood.

[-] [email protected] 2 points 1 year ago

Ah. No, keep reading:

In a less than optimal world, you might decide to do something less inspired. You might take that break from the C runtime and then just implement threads again, with basically the same semantics, except that they are scheduled in userspace. Your users would be required to implement concurrency in terms of threads, locks and channels, just like they had always been in the past. You might also decide your language should have other classic features like null pointers, default constructors, data races and GOTO, for reasons known only to you. Maybe you would also drag your feet for years on adding generics, despite frequent user requests. You might go do that, in a less than optimal world.

(Emphasis on "go" is in the original.)

[-] [email protected] 2 points 1 year ago

Lol.

just implement threads again, with basically the same semantics, except that they are scheduled in userspace

To be fair, the Go implementation here is quite interesting since it scales way better than OS threads, so there are fewer downsides to spinning up a ton of threads. So it's closer to async abstracted behind a threading veneer, like the GREEN functions in the article.

Though the "known only to you" criticisms are absolutely on-point.

[-] [email protected] 2 points 1 year ago

Yeah, Boats' point there is definitely about semantic correctness rather than performance. Goroutines do indeed have good performance.

this post was submitted on 04 Feb 2024

45 points (100.0% liked)

Rust

7190 readers

6 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 2 years ago

MODERATORS

[email protected]