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

Maybe Rust isn’t a good tool for massively concurrent, userspace software

bitbashing.io

Post reply on HN
Print view View original

261–270 of 624 posts

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#261

Post by anonymoushn »

HippoBaro wrote: post #230
jandrewrogers wrote: post #184

Earlier quoted context omitted.

> because stackfull coroutine requires a runtime that preempts coroutines I've used stackful coroutines many times in many codebases. It never required or used a runtime or preemption. I'm not sure why having a runtime that preempts them would even be useful, since it defeats the reason most people use stackful coroutines in the first place.

> I've used stackful coroutines many times in many codebases. It never required or used a runtime or preemption. Can you tell us which? Go, Haskell and the other usual suspect all have runtime with automatic, transparent preemption.

Lua comes with this sort of thing. OCaml, Python, and C have libraries providing this sort of thing in decreasing order of adoption.

Python also comes with 2 features that seem to be stackless coroutines with attached syntax ceremonies, but one of those 2 features is commonly used with a hefty runtime instead of being used for control flow. JavaScript comes with 2 features named similarly to those of Python, but only one of them seems to be "runtime-free" stackless coroutines.

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#262

Post by Animats »

sillysaurusx wrote: post #259
Animats wrote: post #223

OK, I suppose I should write to this. As I've mentioned before, I'm writing a high performance metaverse client. Here's a demo video.[1] It's about 40,000 lines of Rust so far. If you are doing a non-crappy metaverse, which is rare, you need to wrangle a rather excessive amount of data in near real time. In games, there's heavy optimization during game development to prevent overloading the play engine. In a metavers…

Cheering for your metaverse app. Hope to hear more about it. I suspected you might be doing gamedev but this is the first time you’ve shown extensive work. One challenge with rust is that (for better or worse) most gamedev talent is C++. If you ever open source it I’d be interested in contributing, though I’m not sure how effective the contributions would be. Good luck!

Email sent.

I'm not that interested in self-promotion here as I am in getting more activity on Rust graphics development. I think the Rust core graphics ecosystem needs about five good graphics people for a year to get unstuck. Rust is a good language for this sort of thing, but you've got to have reliable heavy machinery down in the graphics engine room.

Until that exists, nobody can bet a project with a schedule and a budget on Rust. The only successful commercial high-detail game title I know of that uses Rust is a sailing race simulator. They simply linked directly to "good old DX11" (Microsoft Direct-X 11) and wrote the game logic in Rust. Bypassed Rust's own 3D ecosystems completely.

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#263

Post by SkiFire13 »

hedora wrote: post #100

I've been writing a lot of async lock free rust. The main problem is that tokio futures are 'static, which is because of a design mistake that's baked deep into the rust ecosystem: Leaking memory is 'safe'. This implies that you can't statically guarantee that a future is cleaned up properly, which means that if you spawn some async work, something may std::mem::forget a future, and then the borrow checker won't know…

> which is because of a design mistake that's baked deep into the rust ecosystem: Leaking memory is 'safe'.

Would you prefer not to have internal mutability, not to have `Rc`, or have them but with infectious unsafe trait bounds, or something else?

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#264

Post by travisgriggs »

technojamin wrote: post #222
whoknowsidont wrote: post #202

Use Erlang/Elixir for orchestration and call into rust implementations. It's an amazing combination.

Elixir/Rust is the new Python/C++, and Rustler makes the communicating between the 2 languages super easy: https://github.com/rusterlium/rustler

And if Zig feels like it fits the gestalt of Elixir/Erlang better for you... then there's Zigler (https://hexdocs.pm/zigler/Zig.html). The fact that you can just "insert a little zig code right here" in the middle of your Elixir code in a ~Z sigil is the coolest darn thing there is. I haven't seen something that cool in the way of embedding performance enhancing fragments/snippets in another dynamic/expressive system since Klaus Gittinger's Smalltalk/X (https://live.exept.de/doc/online/english/programming/primiti...)

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#265

Post by SkiFire13 »

Taek wrote: post #151

Rust made a critical safety mistake when it chose its async paradigm. It gave the code the option to decide when to yield. What that means is that when I'm writing async code, I have to audit every library I import to make sure that library is guaranteed to yield after a few microseconds of execution, otherwise my own core loops starve. Importing unknown code when using async rust is not safe for any application that…

> Rust should change the scheduler

Rust doesn't have a scheduler, and having one would be a no-go for any sufficiently low level code (e.g. in microcontrollers).

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#266

Post by elcritch »

Animats wrote: post #223

OK, I suppose I should write to this. As I've mentioned before, I'm writing a high performance metaverse client. Here's a demo video.[1] It's about 40,000 lines of Rust so far. If you are doing a non-crappy metaverse, which is rare, you need to wrangle a rather excessive amount of data in near real time. In games, there's heavy optimization during game development to prevent overloading the play engine. In a metavers…

Good luck on the metaverse app! I'd love to see more interesting metaverse takes.

One quibble though. Rust isn't race condition free, it's data race free. You can still end up with race conditions outside of data access. https://news.ycombinator.com/item?id=23599598

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#267

Post by winrid »

winrid wrote: post #260
Animats wrote: post #257

Earlier quoted context omitted.

Is there video or a demo?

I don't have anything recorded from the past few years. Here's an old video: https://youtu.be/L7XIFC2SawY?si=qN7TNxZi-P05uXVa It's basically a custom 3D multithreaded OSM renderer, and the assets are a custom binary format. Uses very little network bandwidth. Hoping to have an update this year that shows the updated graphics. I wrote a UI framework to improve my productivity (live hot reloading of UI components writt…

You can sign up to be notified if I ever get it done :) here https://tdworldgame.com/

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#268

Post by yankput »

mrkline wrote: post #34
fzeindl wrote: post #22

Async Everything is a bad language. Async/await was a terrible idea for fixing JavaScript's lack of proper blocked threading that is currently being bolted onto every language. It splits every language and every library-ecosystem in half and will cause pains for many years to come. Everyone who worked with multi-threading outside of JavaScript knows that using actors/communicating sequential processes is the best way…

> Async/await was a terrible idea for fixing JavaScript's lack of proper blocked threading that is currently being bolted onto every language. As fun as it is to hate on JavaScript, it's really interesting to go back and watch Ryan Dahl's talk introducing Node.js to the world ( https://www.youtube.com/watch?v=EeYvFl7li9E ). He's pretty ambivalent about it being JavaScript. His main goal was to find an abstraction aro…

It’s so interesting that the async/await stuff basically makes his presentation points meaningless? if you’re just using the async/await why use the callback style in the first place…

but I get it, you can always go back to the promises and callbacks if you want.

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#269

Post by Rochus »

KMag wrote: post #175
bluGill wrote: post #146

Earlier quoted context omitted.

Why does Smalltalk constantly get credit for being true OOP? Simula was doing OOP long before Smalltalk. Most languages choose Simula style OOP, and reject the things that make Smalltalk different. If you say Smalltalk is better OOP I might agree, but calling it "true" is not correct.

Alan Kay is generally credited with coming up with the term "object-oriented", so for better or for worse, many people defer to his definition and his embodiment of ideas when looking for a strict definition of the term.

> many people defer to his definition and his embodiment of ideas when looking for a strict definition of the term.

I consider the definition e.g. used by IEEE as sufficiently strict, see e.g. https://ethw.org/Milestones:Object-Oriented_Programming,_196..., but - as you say - it's not the defintion used by Kay.

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#270

Post by pornel »

divyekapoor wrote: post #80

We do not want red and blue functions. Any language that implements async / await as coroutines instead of green threads is making a fundamental CS mistake. https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... Concurrency's correct primitive is Hoare's Communicating Sequential Processes mapped onto green threads. Some languages that have it right are Java (since JDK17 - Java Virtual Threads), Go, Kotlin.

This classic article mixes two things:

1. inability to read an async result from a sync function, which is a legitimately major architectural limitation.

2. author's opinion how function syntax should look like (fully implicit, hiding how the functions are run).

And from this there is the endless confusion and drama.

The problem 1 is mostly limited to JS. Languages that have threads can "change colour" of their functions at will, so they don't suffer from the dramatic problem described in the article.

But people see languages don't fit the opinion 2, of having magic implicit syntax, and treat it as an equally big deal the dead-end problem 1. But two syntaxes are somewhere between minor inconvenience to actual feature. In systems programming it's very important which type of locks you use, so you really need to know what runs async.

Post reply on HN