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

11–20 of 127 posts

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

#11

Post by RyanZAG »

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?

Java doesn't use system memory management by default, but rather keeps its own heap for garbage collection. If you start your java daemon with -Xms5000m -Xmx5000m then java will use 5GB of ram and use that to allocate new objects inside it. Depending on the garbage collector used, Java may wait until that 5GB is full before clearing it out, therefore using "up to 5GB of RAM" for the same 50MB dataset in a long running process.

It's not really a useful comparison for most uses of java though.

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

#12

Post by cpursley »

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…

Neat, what is your use-case for OBD-II data? I've been investigating ways to get data from a race car back to the pit crew via something like a raspberry pi.

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

#13

Post by squiguy7 »

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?

This most likely has to do with their respective memory models. Rust will try and allocate most things on the stack unless an item is explicitly wrapped in a Box. This isn't the only exception however. I can't speak to Java's model but I imagine it places more things on the heap.

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

#14

Post by Q6T46nT668w6i3m »

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?

Java caches the universe. ;)

(FWIW, it’s an apples-to-oranges comparison from a compilation, linking, packaging, etc. perspective, but from an end-user perspective I think it’s a reasonable claim.)

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

#15

Post by paulddraper »

revelation wrote: post #10
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?

Java has its own heap so the memory usage, certainly for a server VM, doesn't necessarily correspond to actual application memory use. (Also, of course, your main server uses "up to" 5 GiB? That's fucking great. Until it goes beyond 64 GiB, who even cares. Work on something that has a worthwhile monetary return..)

Assuming it is heap space: that just prompts the question why is there heap space so large?

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

#16

Post by notriddle »

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 same performance. https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

* Like vegetarians, Rustaceans pay more attention to efficiency as a whole. This may give the appearance of Rust being more efficient, even if it's actually not.

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

#17

Post by jacquesm »

cpursley wrote: post #12
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…

Neat, what is your use-case for OBD-II data? I've been investigating ways to get data from a race car back to the pit crew via something like a raspberry pi.

The microcontroller component of that is going to be a walk in the park compared to the radio component.

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

#18

Post by chatmasta »

notheguyouthink wrote: post #9
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…

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

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

#19

Post by sagichmal »

notheguyouthink wrote: post #9
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…

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

> Can someone explain to me what async/await is, in the context of a language like Go?

As far as I know:

    c := make(chan int)
    go func() { c

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

#20

Post by ehsanu1 »

notheguyouthink wrote: post #9
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…

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

Goroutines allow you to write async code ergonomically. Without those, you'd have to write callbacks, which is very unergonomic.

Here's a before and after diff of some prototype async/await usage in Rust: https://github.com/mehcode/shio-rs/commit/8078a34c075bf2f52c...

Post reply on HN