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

571–580 of 624 posts

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

#571

Post by Animats »

d3ckard wrote: post #493
Animats wrote: post #262

Earlier quoted context omitted.

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 an…

Any pointers on what exactly is missing? I am neither a Rust guy or a graphics guy, but I have some interest in what is missing in the ecosystem.

> Any pointers on what exactly is missing?

Yes. [1]

[1] https://www.reddit.com/r/rust_gamedev/comments/13qt6rq/were_...

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

#572

Post by throw10920 »

zdragnar wrote: post #471
throw10920 wrote: post #420

Earlier quoted context omitted.

> The difference is that if you get it wrong in a managed language, you get leaks or stale objects or other logic bugs. Can you provide concrete examples of this? I've literally never had a bug due to the nature of a memory-managed language.

Once upon a time (at least through IE7) Internet Explorer had separate memory managers for javascript and the DOM. If there was a cycle between a JS object and a DOM object (a DOM node is assigned as a property of an object, and another property was assigned as an event handler to the DOM node) then IE couldn't reclaim the memory. Developers of anything resembling complex scripts (for the time) had to manually break…

My question was about the nature of a memory-managed language causing "leaks or stale objects or other logic bugs". This issue is not that - this is due to a buggy implementation causing memory leaks.

To be more precise: this is a bug, that was fixable, in the runtime, not in user applications that would run on top of it.

Assume a well-designed memory-safe language and implementation. What kinds of memory hazards are there?

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

#573

Post by throw10920 »

pkolaczk wrote: post #489
throw10920 wrote: post #404

Earlier quoted context omitted.

> So what I'm saying, you need to put in this work no matter which language you choose This is very false. Managed-memory languages don't require you to even think about lifetimes, let alone write them down. Yes, I understand that this is for efficiency - but claiming that you have to think about lifetimes everywhere is just wrong, and irrelevant when discussing topics (prototyping/design work/scripting) where you do…

> Managed-memory languages don't require you to even think about lifetimes, let alone write them down. Memory is only one of many types of resources applications use. Memory-managed languages do nothing to help you with those resources, and effectively managing those resources is way harder in those languages than in Rust or C++.

What? Rust doesn't do anything to "help you with those resources", either - you can still create cycles in ARC objects or allocate huge amounts of memory and then forget about it.

In both languages you have to rely on careful design, and then profile memory use and manage it.

However, Rust requires you to additionally reason about lifetimes explicitly. Again - great for performance, terrible for design, prototyping, and tools in non-resource-constrained environments*.

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

#574

Post by cma »

politician wrote: post #235
Pauan wrote: post #160

Earlier quoted context omitted.

Rust embraces abstractions because Rust abstractions are zero-cost. So you can liberally create them and use them without paying a runtime cost. That makes abstractions far more useful and powerful, since you never need to do a cost-benefit analysis in your head, abstractions are just always a good idea in Rust.

> abstractions are just always a good idea The "zero-cost" phrase is deceptive. There's a non-zero cognitive cost to the author and all subsequent readers. A proliferation of abstractions increases the cost of every other abstraction further due to complex interactions. This is true of in all languages where the community has embraced the idea of abstraction without moderation.

It also often makes debugging harder.

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

#575

Post by hot_gril »

sealeck wrote: post #546
hot_gril wrote: post #173

Earlier quoted context omitted.

Anything that waits on I/O needs concurrency (but not necessarily threads). Web backends, web frontends, deeper backends, desktop GUIs, that's probably 90% of software right there.

Rust is a systems programming language though.

I interpreted the 99% thing as referring to all software. If it's just Rust projects then sure, then again anyone who needs async has probably been avoiding a language that lacked async until recently.

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

#576

Post by [deleted] »

likeabbas wrote: post #541
withoutboats3 wrote: post #524

Earlier quoted context omitted.

I designed async/await and I absolutely did take this into account. I designed it to be as pleasant as possible under the constraints.

Can you admit that you failed in making it a pleasant experience to write async, especially for library authors? I don’t think it’s too late to admit failure and implement something like May https://github.com/Xudong-Huang/may

[deleted]

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

#577

Post by withoutboats3 »

likeabbas wrote: post #541
withoutboats3 wrote: post #524

Earlier quoted context omitted.

I designed async/await and I absolutely did take this into account. I designed it to be as pleasant as possible under the constraints.

Can you admit that you failed in making it a pleasant experience to write async, especially for library authors? I don’t think it’s too late to admit failure and implement something like May https://github.com/Xudong-Huang/may

no, I don't admit that, and I think you're an enormous asshole

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

#578

Post by lelanthran »

jayd16 wrote: post #553
lelanthran wrote: post #491

Earlier quoted context omitted.

> Yes actually it is solved. If you stick to async then it cannot deadlock (in this way) because you yield execution to await. Maybe I'm misunderstanding what you are saying. I use the word "_implementation_type_" below to mean "either implemented as option 1 or option 2 from my post above." With current asynchronous implementations (like JS, Rust, etc), any time you use `await` or similar, that statement may never r…

I'm referring to the situation where a synchronous wait consumes the thread pool, preventing any further work. A is sychrounously waiting B which is awaiting C which could complete but never gets scheduled because A is holding onto the only thread. Its a very common situation when you mix sync and async and you're working in a single threaded context, like UI programming with async. Of course it can also cause starva…

That's an implementation problem, not a problem with the concept of asynchronous execution, and it's specifically a problem in only one popular implementation: Javascript in the browser without web-workers.

That's specifically why I called it a Leaky Abstraction in my first post on this: too many people are confusing a particular implementation of asynchronous function calls with the concept of asynchronous function calls.

I'm complaining about how the mainstream languages have implemented async function calls, and how poorly they have done so. Pointing out problems with their implementation doesn't make me rethink my position.

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

#579

Post by kunley »

SubjectToChange wrote: post #566
kunley wrote: post #292

Earlier quoted context omitted.

As an ops guy for decades, it makes me laugh to hear claims about Java GC superiority. Please go back in time and fix all the crashes and OOMs caused by enterprise JVM, as opposed to near-zero problems with the Go deployments. Making stong statements without a backup in hard facts is a sign of zealotry...

it makes me laugh to hear claims about Java GC superiority. Please go back in time and fix all the crashes and OOMs caused by enterprise JVM, I don’t see how running into an OOM problem is necessarily a problem with the GC. That said, Java is a memory intensive language, it’s a trade off that Java is pretty up front about. I don’t have a horse in this race but I would be quite surprised if Go’s GC implementation coul…

Java has billions spent on marketing and lobbying.

Since the advent of Java in mid-90s I hear about superiority of its VM, yet my observations from the ops PoV claim otherwise. So I suspect a huge hoax...

Hey btw, you're saying "Java is _memory intensive_", like it would magically explain everything. Let's get to that more deeply. Why is it so, dear Watson? Have you compared the memory consumption of the same algo and pretty much similar data structures between languages? Why Java has to be such a memory hog? Why also its class loading is so slow? Are these a qualities of superior VM design and zillions of man-hour invested? huh?

By the way, if the code implementing functionality X needs N times more memory than the other language with gc, then however advanced that gc would be (need to find a proof for that btw), it wouldn't catch up speedwise, because it simply needs to move around more. So simple.

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

#580

Post by sliken »

jstx1 wrote: post #322
pshc wrote: post #313

Earlier quoted context omitted.

Debugging rare crashes and heisenbugs is more frustrating, and in non-safe languages, a chronic problem. Whereas after you prove the safety of a design once, it stays with you.

It stays with you until you need to change something and find yourself unable to make incremental changes. And in many use cases people are throwing Rust (and especially async Rust) on problems solved just fine with GC languages so the safety argument doesn’t apply there.

Sort of. Do you want someone that doesn't understand the constraints that likely is creating a bug that will cause crashes? Or do you want to block them until they understand the constraints?
Post reply on HN