Live data from Hacker News

How Rust Is Tilde’s Competitive Advantage [pdf]

rust-lang.org

81–90 of 127 posts

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#81
post #70
post #66

Earlier quoted context omitted.

Goroutines are not the same thing as Go channels.

Sorry, yes. Fibers (Go didn't invent them) also aren't directly equivalent because they don't allow explicit yields and composition.

Fibers don't, but goroutines + channels + closures do. They permit composition using the same call/return syntax and semantics as normal function calls.

Futures and promises don't. Async/await is closer, but only by creating a second class of function incompatible with normal functions.

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#82
post #63

Earlier quoted context omitted.

I call bullshit. Most probably their Java code was FUBAR.

> Most probably their Java code was FUBAR. And so what? If a language's natural form leads to FUBAR code, what else is to blame?

Nice false premise there. It could easily be caused by other things.

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#85

Wow, that paper needs a tl;dr.

Really? For a 6 white paper?

Fine:

Tilde built a server monitoring daemon with Rust and it's low resource and doesn't crash. Tilde thinks the Rust community & its resources make it easier to teach to new team members.

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#86
post #81
post #70

Earlier quoted context omitted.

Sorry, yes. Fibers (Go didn't invent them) also aren't directly equivalent because they don't allow explicit yields and composition.

Fibers don't, but goroutines + channels + closures do. They permit composition using the same call/return syntax and semantics as normal function calls. Futures and promises don't. Async/await is closer, but only by creating a second class of function incompatible with normal functions.

[deleted]

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#87

> while the Java server could use up to 5GB of RAM, the comparable Rust server only used 50MB How...how is that possible? It just glosses over this interesting point. What does "comparable" Java code do to use 100x more memory?

Almost certainly either bad design (their Java app had a way bigger working set than their Rust one), or bad tuning (they set the heap needlessly large). Automatic memory management _does_ require more memory for reasonable performance, but you'd be talking about 2x or 3x the working set. Not 100x. Java objects will likely end up a little larger than Rust ones, but again not enough to make up the 100x difference. Hav…

> or bad tuning (they set the heap needlessly large)

The claim "for equivalent Java code", might be slightly exaggerated, but looking at the claim as a whole: "Rust is Tilde's Competitive Advantage", "bad tuning" is part of the point.

"bad tuning" usually means "no tuning". Which means they spent the time they could have been tuning and used it to build features instead, or optimize their code instead.

From that perspective I wouldn't use "bad tuning" as an argument for continuing to use Java.

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#88

Wow, that paper needs a tl;dr.

Really? For a 6 white paper? Fine: Tilde built a server monitoring daemon with Rust and it's low resource and doesn't crash. Tilde thinks the Rust community & its resources make it easier to teach to new team members.

Yes, really. It's not the length, it's the density of interesting content.

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#89

Earlier quoted context omitted.

Really? For a 6 white paper? Fine: Tilde built a server monitoring daemon with Rust and it's low resource and doesn't crash. Tilde thinks the Rust community & its resources make it easier to teach to new team members.

Yes, really. It's not the length, it's the density of interesting content.

Yeah man, learning to scan a paper for interesting content is definitely a skill worth developing!

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#90
post #44

Earlier quoted context omitted.

> Using a language for a large project without some kind of async/await notation seems painful. How bad is it using only combinators for async (assuming you want to stay on stable)? And is there a date yet when async/await will be stabilized? Can someone explain to me what async/await is, in the context of a language like Go? I've used Rust a fair amount, but Go has been my native language for ~5 years now. With that…

async/await means you mark all your yield points explicitly; rather than having the runtime implicitly preempt you whenever it chooses, you mark the points at which task switching can happen, and at every other point it's impossible (equivalently it's as though any block of code that doesn't contain an "await" were a critical section). The syntax strikes a nice balance, making these markers as lightweight as possible…

Having used both, I'd be pretty shocked if anyone found Twisted to be easier to reason about or less prone to bugs than Go...
Post reply on HN