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

How Rust Is Tilde’s Competitive Advantage [pdf]

rust-lang.org

Post reply on HN
Print view View original

61–70 of 127 posts

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

#61

Post by naasking »

coldtea wrote: post #57
Nelkins wrote: post #2

So, I've been eyeing Rust for a while and have messed around with it a bit in my free time. Here are some things I'd want to know before trying it out on a large project: 1. What development environment are other developers using with very large code bases? Is the tooling responsive? 2. Using a language for a large project without some kind of async/await notation seems painful. How bad is it using only combinators f…

> 2. Using a language for a large project without some kind of async/await notation seems painful And yet most of the software we use, billions of lines of code, from Chrome to Linux, from Photoshop to bind, and from Nginx to Skype, has been created without such notation. Somehow we've managed.

"Managed" and "seems painful" don't disagree with each other.

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

#62

Post by steveklabnik »

mjal wrote: post #56
steveklabnik wrote: post #8

Earlier quoted context omitted.

Understood :) I usually try to be really clear about what my opinion is based on, especially when it's second-hand, like with IntelliJ. Have you tried debugging with CLion? I don't own a license so I haven't tried myself.

CLion debugging works pretty well for most cases, though there are some small issues every so often. I always make sure to report them to the appropriate place if they're not known already, though.

Great, thanks!

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

#63

Post by mda »

paulddraper wrote: post #3

> 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?

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

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

#64

Post by ronjouch »

steveklabnik wrote: post #23
notheguyouthink wrote: post #9

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…

Yeah, you are missing some details. But this is a huge area, and it's hard to explain in a single HN comment. Basically, yes, the convenience of not needing to write async/await is useful, but in order to accomplish that, you need a bunch of other supporting decisions. These decisions make sense for Go, but do not make sense for Rust. The first thing to say on this topic is that virtually all of this (including async…

Adding a recent detailed take on the situation, by another Rustlang contributor: https://manishearth.github.io/blog/2018/01/10/whats-tokio-an... . Hope that helps :)

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

#65

Post by quotheth »

notriddle wrote: post #16
paulddraper wrote: post #3

> 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?

Three things: * Java tends to allocate things separately and manipulate pointers, while Rust allocates things inline. This introduces allocation overhead and eats up the space needed by the pointers themselves. * Java uses a JIT, which consumes of memory for profiling state and for storing the resulting compiled code. * A tracing garbage collector needs about five times as much memory as explicit freeing to reach the…

None of these are likely the reason - it should be as simple as Java's own managed heap preallocating that space.

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

#66

Post by wahern »

eropple wrote: post #50
chatmasta wrote: post #18

Earlier quoted context omitted.

Async/await makes sense in python or JavaScript because it’s syntactical sugar that improves readability/maintainability and mitigates against concurrency errors stemming from the event loop (JS) or the GIL (python). I haven’t worked with Go beyond playing with it a bit, but it seems async/await would be utterly useless in Go since goroutines already accomplish the same thing in a much more performant manner.

C# was, as far as I'm aware, the first major language to implement async/await atop of Task (akin to Java's Future ). The CLR uses native threads. Go channels are also orthogonal to async/await. Message passing is not a substitute for futures/tasks, though it can be used to achieve similar goals. I would be extremely cautious about claiming that Go channels would be "more performant" than an otherwise-equivalent futu…

Goroutines are not the same thing as Go channels.

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

#67

Post by pnkfelix »

naasking wrote: post #59
notriddle wrote: post #16

Earlier quoted context omitted.

Three things: * Java tends to allocate things separately and manipulate pointers, while Rust allocates things inline. This introduces allocation overhead and eats up the space needed by the pointers themselves. * Java uses a JIT, which consumes of memory for profiling state and for storing the resulting compiled code. * A tracing garbage collector needs about five times as much memory as explicit freeing to reach the…

5 times the memory is a serious exaggeration. At least twice, but no more than 3x.

The linked Wikipedia page references a OOPSLA 2005 paper by Matthew Hertz and Emery D. Berger that presents data saying that with 3x memory you might reasonably expect a 17% slowdown when compared to manual memory management. (And 70% slowdown when limited to 2x memory.)

Of course there have been some advanced in GC technology since 2005 (and that paper was deliberately measuring a relatively standard generational approach). But I don’t think I’d call the 5x figure a serious exaggeration.

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

#68

Post by jahaja »

I've come to realize that the main thing that is making me procrastinate giving Rust a proper go is entirely superficial at this point. Basically it looks like a "clever" programmers dream language - which is usually not my cup of tea. I'm also worried that larger projects ("real-world" projects, so not projects like Servo) will inevitably become an illegible mess when clever programmers makes the most of a clever language.

That said, I plan to push through this admittedly superficial barrier in the near future and hopefully calm this concern.

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

#69

Post by spease »

Nelkins wrote: post #2

So, I've been eyeing Rust for a while and have messed around with it a bit in my free time. Here are some things I'd want to know before trying it out on a large project: 1. What development environment are other developers using with very large code bases? Is the tooling responsive? 2. Using a language for a large project without some kind of async/await notation seems painful. How bad is it using only combinators f…

Nightly rust can use this async / await crate, but it will likely be deprecated once language support is available (later this year iirc)

https://github.com/alexcrichton/futures-await/blob/master/RE...

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

#70

Post by eropple »

wahern wrote: post #66
eropple wrote: post #50

Earlier quoted context omitted.

C# was, as far as I'm aware, the first major language to implement async/await atop of Task (akin to Java's Future ). The CLR uses native threads. Go channels are also orthogonal to async/await. Message passing is not a substitute for futures/tasks, though it can be used to achieve similar goals. I would be extremely cautious about claiming that Go channels would be "more performant" than an otherwise-equivalent futu…

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.
Post reply on HN