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

Rust and the Future of Systems Programming [video]

hacks.mozilla.org

Post reply on HN
Print view View original

241–250 of 511 posts

Re: Rust and the Future of Systems Programming [video]

#241

Post by naasking »

qwertyuiop924 wrote: post #230
naasking wrote: post #157

Earlier quoted context omitted.

The latency problem isn't caused by determining what to free, the latency problem is caused by actually freeing . Imagine an array with 2^31 pointers, and now fill it with with 2^31 distinct pointers to the remainder of the 2^32 bit address space. When that array goes out of scope, you can now enjoy 2^31 individual free operations, because reclamation for Rust lifetimes and reference counting are both proportional to…

Ah. But C has this problem as well. If you've malloc(3)ed an array of 2^31 pointers, each pointing to an object, enjoy your 2^31 free(3)s, or prepare to start leaking RAM. So what's your point?

Yes, C/C++ and Rust have the same problems, as I said elsewhere. My ultimate point is that low latency is a property of a runtime, not a language. Using C/C++ or Rust aren't going to automatically give you bounded latency, and adding tracing GC doesn't automatically take it away.

Re: Rust and the Future of Systems Programming [video]

#243

Post by Matthias247 »

josephg wrote: post #163
rwj wrote: post #150

Earlier quoted context omitted.

I think the idea would be the program would fail to compile, and you would need to go back and replace the unwrap with proper error handling. The goal would be to allow the use of unwrap during development, but require the final polish before the code goes into production.

unwrap is proper error handling. It says "Try to do this. If it fails, panic". Its like an assert on an invariant that the compiler requires. If my script depends on a database connection, I might connect to a database and unwrap() it so the script errors out if the database isn't available. If I wrote that logic myself I would just be awkwardly rewriting unwrap.

> If my script depends on a database connection, I might connect to a database and unwrap() it so the script errors out if the database isn't available.

I think that's a bad example, as it is one of those things that can really fail at runtime and which should be properly handled. Even if handling means printing an error message and stopping the process with an exit code - but not crashing.

I think unwrap is for things that really should not happen if everything is implemented correctly.

Re: Rust and the Future of Systems Programming [video]

#244

Post by Manishearth »

naasking wrote: post #240
Manishearth wrote: post #224

Earlier quoted context omitted.

> For instance, the cascading free behaviour Rust is currently susceptible to can be broken up into a bounded series of free operations interleaved with ordinary program execution. You can probably make this work by plugging in a different allocator, if jemalloc doesn't do this already. The ability to batch up frees and mallocs isn't tied to GCs. This won't reduce the perf impact of running a large tree of `Drop` imp…

> You can probably make this work by plugging in a different allocator, if jemalloc doesn't do this already. The ability to batch up frees and mallocs isn't tied to GCs. That gets tricky, because Rust people no doubt expect deterministic destruction on scope exit. But yes, my ultimate point is that low latency is a property of a runtime, not a language. C/C++ or Rust aren't going to automatically give you bounded lat…

> Rust people no doubt expect deterministic destruction on scope exit.

Deterministic destruction, but not deterministic deallocation :)

Re: Rust and the Future of Systems Programming [video]

#245

Post by [deleted] »

pron wrote: post #51
hinkley wrote: post #40

Earlier quoted context omitted.

If I had infinite free time, I'd love to explore the problem space of implementing interpreters for GC-based languages on top of Rust. It's quite hard to get the concurrency right, and indeed we see a number of major languages that gave up on even trying.

What for? If you have the extra RAM and power for a GC, you don't need Rust for safety. HotSpot's next-gen (JIT) compiler is written in Java and is absolutely amazing.

[deleted]

Re: Rust and the Future of Systems Programming [video]

#246

Post by leshow »

duneroadrunner wrote: post #226
pcwalton wrote: post #173

Earlier quoted context omitted.

"Safer C++", like all C++ template libraries, is not memory safe.

Are you confusing SaferCPlusPlus with a different library? SaferCPlusPlus is a new library that makes it practical to stick to a memory safe subset of C++ (i.e. no native pointers, no native arrays, no std::array , no std::vector , etc.). Using the SaferCPlusPlus library to replace all uses of C++'s unsafe elements does result in code that is as memory safe as Rust, or any other modern language. The main shortcoming…

Correct me if I'm wrong, but it looks like this just provides some 'safe' alternatives to unsafe C++ things. It's still up to the diligence of the programmer to not use those things and nothing is getting statically verified.

By contrast, when I write Rust, memory safety (and type safety) are verified by the compiler.

Re: Rust and the Future of Systems Programming [video]

#247

Post by steveklabnik »

oldsj wrote: post #242
anfroid555 wrote: post #189

Anyone know a tutorial course for someone only knowing high level languages. And not c or Ruby. More JavaScript, PHP, nodejs, Python

Rust for rubyists?

It basically doesn't exist anymore; I stopped maintaining it pre-Rust 1.0.

Re: Rust and the Future of Systems Programming [video]

#248

Post by papaf »

steveklabnik wrote: post #66
djhworld wrote: post #50

I keep trying to learn rust but fail miserably. They do say on their website that there's a hump that you have to climb over before everything fits into place, which is probably applicable to everything you'll learn, but sometimes I think that hump is too much of a hurdle

How are you trying? What are you getting stuck on? I'd love to improve things.

What are you getting stuck on? I'd love to improve things.

I feel I am getting over the hump of learning rust now and coding in rust is becoming less frustrating for me.

However, one thing that slows me down is the lack of indices in the documentation. For instance, if I want to know the return type of a vector len() I go here:

https://doc.rust-lang.org/std/vec/struct.Vec.html

.. and then I have to search the web page for all instances of "len". It would be good if there was an index similar to Javadoc, Godoc or Doxygen.

There might be a good reason for not having the index, but as a beginner it is lost on me.

Re: Rust and the Future of Systems Programming [video]

#249

Post by qwertyuiop924 »

naasking wrote: post #241
qwertyuiop924 wrote: post #230

Earlier quoted context omitted.

Ah. But C has this problem as well. If you've malloc(3)ed an array of 2^31 pointers, each pointing to an object, enjoy your 2^31 free(3)s, or prepare to start leaking RAM. So what's your point?

Yes, C/C++ and Rust have the same problems, as I said elsewhere. My ultimate point is that low latency is a property of a runtime, not a language. Using C/C++ or Rust aren't going to automatically give you bounded latency, and adding tracing GC doesn't automatically take it away.

Oh.

Well then actually, we're in complete agreement. Sorry.

Re: Rust and the Future of Systems Programming [video]

#250

Post by Matthias247 »

naasking wrote: post #179
akiselev wrote: post #174

Earlier quoted context omitted.

You will always have these pathological cases when you choose to use higher level memory management like simple reference counting or garbage collection no matter what language you use, whether it's Rust or assembler. The point of Rust is that you have complete control over what you use and pay for. If your concern is the overhead of lifetimes then you need to evaluate if you can afford heap allocation in the first p…

> You will always have these pathological cases when you choose to use higher level memory management like simple reference counting or garbage collection no matter what language you use Not true, soft and hard realtime garbage collectors exist. Your runtime simply needs to bound the amount of reclamation work done at any given time. For instance, the cascading free behaviour Rust is currently susceptible to can be b…

> Your runtime simply needs to bound the amount of reclamation work done at any given time.

Wouldn't this transform the problem into a "no more predictable maximum memory usage" problem? As you can't really know if and when your GC will keep up it with the amount of work to do.

Post reply on HN