Live data from Hacker News

Async Rust never left the MVP state

tweedegolf.nl

271–273 of 273 posts

Re: Async Rust never left the MVP state

#271

Earlier quoted context omitted.

That’s part of it. Then you add a thread pool to dispatch your tasks into to mitigate the cost of a thread start. Then you run into blocking problems and are like “I wish I had some keyword to express when a function needed to be run on the thread pool”. Then you’ve done a speed run of the past 40 years of research.

The 40 years of research was actually in OS theory so that you could write normal code and async was abstracted away. A thread pool is not a research project.

Speed run of 40 years of language development. If you follow OS research you know that field has drastically stagnated. We pretend like an OS “is the thing” and yet we actually have a distributed systems problem on our hands with each piece of hardware often running its own CPU and OS.

Re: Async Rust never left the MVP state

#272
post #203
post #182

Earlier quoted context omitted.

commons, is something that is eventually being migrated into the main, at least those that are decided to be required for most projects. I don't use apache commons or guava at all in java (now at 25 or 26, depending on project) - there are still some libs that depend on those, but I would argue that most use it out of inertia, than actual need. As for slf4j, I still don't see any justification for an abstraction laye…

The logging implementation should be an application level decision. By using a facade like slf4j a library allows an application using any logging implementation to use it. That’s why libraries should use it.

Oh, yeah - libraries yes. But for application code it is useless.

Re: Async Rust never left the MVP state

#273
post #268

Earlier quoted context omitted.

When did you last use IntelliJ, 30 years ago? I've never seen it fail to lay out dialogs correctly, windows do have minimum sizes, and I haven't seen any focus bugs.

> lay out dialogs correctly This might be specific to X11. The initial size of the window is miscalculated when it first opens and a moment later changes by a few pixels, causing the contents to visually shift slightly. This happens with dialog windows the first time they're opened. > windows do have minimum sizes My mistake, I meant maximum size. > and I haven't seen any focus bugs I was being a bit vague because I'…

Hmm, I only use it on macOS for many years now. There might well be bugs on X11, there are so many different WMs and desktop environments that can cause strange interactions and focus/window sizing bugs. But at least for me it's never been buggier than native apps.
Post reply on HN