Rust and the Future of Systems Programming [video] • Hacker News Board

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

#391

Post by blt » Thu, Nov 17, 2016, 5:17 AM UTC

hinkley wrote: post #339

Animats wrote: post #330

Earlier quoted context omitted.

Yes, I know, async I/O is the new cool thing. Here's an async I/O program from 1972.[1] John Walker wrote this. EXEC 8 had the IO$ system call, which, unlike IOW$, returned immediately. A "completion routine" was called when the I/O operation finished. Note how similar those libraries are to what's used today, now that people are reading Dijkstra again. The problem, of course, is that a callback system dominates the…

Where pretty much anything related to concurrency is concerned we've been busy reliving the 70's for most of the last decade. Locking, asynchronous I/O, you name it. Hell even Microsoft had I/O Completion ports back in what, 2003 or so? Or am I wrong and it was a lot earlier? The coolest things in Javascript land were all done by Microsoft first and everyone (me especially) can't bring themselves to acknowledge that.

Web servers and GUI apps are both long-running, event driven programs that need to do IO or slow computations while staying responsive to new events. It's not surprising that they are both well supported by the same programming model. The Win32 API is ugly but the methods of app/OS interaction it supports are fundamentally sound for high performance interactive programs.

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

#392

Post by [deleted] » Thu, Nov 17, 2016, 5:25 AM UTC

Manishearth wrote: post #129

naasking wrote: post #91

Earlier quoted context omitted.

> IMO it would be great to get folks who write the enormous base of existing realtime apps driving critical devices everywhere to sit up and take notice of Rust. Rust cannot make any latency guarantees either. Reference counting and its lifetimes also have pathological cases, ie. worst-case, an object can reference the entire heap which will take time proportional to the number of dead objects to free. Copying collec…

> Rust cannot make any latency guarantees either. Reference counting and its lifetimes also have pathological cases, ie. worst-case, an object can reference the entire heap which will take time proportional to the number of dead objects to free. Rust doesn't use reference counting by default. Refcounting is very rare in Rust, much more rare than it is in C++. Most large C++ codebases I've worked with have thrown in t…

[deleted]

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

#393

Post by naasking » Thu, Nov 17, 2016, 5:43 AM UTC

worik wrote: post #303

naasking wrote: post #205

Earlier quoted context omitted.

> With GC you are not in control so there are fewer choices. You will not be able to make guarantees. Not true. Hard and soft realtime GCs with sub-microsecond latencies exist. Latency is a property of a runtime, not of manual vs. automatic storage reclamation.

That is a misunderstanding of latency. "Very fast" is still latency.

"No latency" is a fiction. The only question of any relevance is how much latency is tolerable for a given domain. And describing latency in worst-case timings is standard, so I understand latency just fine thanks.

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

#394

Post by Animats » Thu, Nov 17, 2016, 5:51 AM UTC

Manishearth wrote: post #320

Animats wrote: post #271

Earlier quoted context omitted.

Trees don't have to be refcounted in Rust. Single-ownership trees are possible. As long as they don't have backpointers. Backpointers are a problem under single ownership.

Right, I never said that trees have to be refcounted. A sufficiently large ownership tree will get deallocated all at once, which is the kind of latency the GP is talking about.

Linked data structures in Rust get complicated, though. See the "Too many lists" book.[1] Doubly linked lists, or trees with backlinks, are especially difficult. Either you have to use refcounts, or the forward pointer and backward pointer need to be updated as an unsafe unit operation. There might be an elegant way to do this with swapping, but I'm not sure yet.

[1] http://cglab.ca/~abeinges/blah/too-many-lists/book/

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

#395

Post by nixos » Thu, Nov 17, 2016, 5:52 AM UTC

z3t4 wrote: post #253

wyager wrote: post #211

Earlier quoted context omitted.

Why would I want to? Better to explicitly convert the number to a string.

This is something you do often in JavaScript, for example: "You have " + messages + " new messages"

And in Java, and in any language with operator overloading

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

#396

Post by duneroadrunner » Thu, Nov 17, 2016, 5:59 AM UTC

Manishearth wrote: post #353

duneroadrunner wrote: post #337

Earlier quoted context omitted.

Well, like I said in the other comment, you guys could fix that by unbundling the static checker in the Rust compiler and making it applicable to (a subset of) C++ code as well :) So then would you agree with the notion that (a practical subset of) C++ combined with a static analyzer could be just as safe and fast as Rust if, hypothetically, there existed an enthusiastic community comparable to Rust's? Or are there i…

> Well, like I said in the other comment, you guys could fix that by unbundling the static checker in the Rust compiler and making it applicable to (a subset of) C++ code as well :) The problem is that you still need extra annotations. Namely lifetime annotations (or something similar relating between borrows -- either that, or use a lot of elision which can be crippling). On top of that, the programming style Rust e…

> The problem is that you still need extra annotations. Namely lifetime annotations

Well, the idea is not to have the static analyzer verify typical C++ code. Just some practical subset. So for example I think it's quite practical to write C++ code that uses only "scope" pointers (basically pointers to objects on the stack) and (not-null) refcounting pointers, that intrinsically don't outlive their targets. Lifetimes would be implied by the types. So wait, what more does Rust's static analyzer give us again? Does it somehow remove the need for refcounting heap objects?

> the programming style Rust encourages is not the same as the ones you tend to see in C++ codebase, and programming in the C++ style will lead to code that doesn't compile.

I have no problem with that. I have no attachment to the "traditional" C++ programming style.

> This might be more tractable (and is an interesting idea). But that optimizer would be hard to write.

Why? The static analyzer has an opinion on whether or not a program is safe. The optimizer just wants to know if it still thinks it's safe when you remove a runtime check.

> I think this is what the new ISOCPP core guidelines are trying to do? Though they don't go far enough in preventing memory unsafety IIRC (this may have changed).

The ISOCPP core guidelines approach is to recommend the use of C++'s intrinsically dangerous elements in a way that is "usually safe", but not always, and rely on their static analyzer to catch bugs. So the question becomes, what do you do in the many cases where the static analyzer doesn't know if it's safe or not. You can try to redesign your code so the static analyzer can understand that it's safe. But that's often very inconvenient or has a performance cost. Often the most practical (safe) solution is to resort to something like SaferCPlusPlus.

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

#397

Post by saaadhu » Thu, Nov 17, 2016, 6:01 AM UTC

qwertyuiop924 wrote: post #325

gcp wrote: post #308

Earlier quoted context omitted.

Uh? There are definitely trimmed libc's (not GNU libc!) that run on bare metal. Such as the one used by avr-gcc for example...

Yeah, but why ? I've never used a libc on embedded, and I'm kind of confused as to why you'd want to. Am I just Doing It Wrong™?

Atleast for avr-gcc, (part of) startup code and vector table layout come from avr-libc.

I'm kinda surprised you got by without libc - no strxxx, memxxx ,xxxprintf/no math.h functions ever?

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

#398

Post by naasking » Thu, Nov 17, 2016, 6:02 AM UTC

akiselev wrote: post #360

naasking wrote: post #179

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

>> 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. That doesn't change anything! You're just choosing a garbage collector with a default deterministic pathological case, which is a guarantee you can make about almost any GC by carefully tailoring your memory usage to your scenario and choice of algorithm. That's all r…

> That doesn't change anything! You're just choosing a garbage collector with a default deterministic pathological case, which is a guarantee you can make about almost any GC by carefully tailoring your memory usage to your scenario and choice of algorithm.

The fact that you don't have to tailor anything is precisely the point. Latency is a property of a runtime, not a language. This has been my point all along. C/C++ or Rust don't guarantee low-latency realtime properties, and introducing tracing GC doesn't guarantee high-latency non-realtime properties.

> You know that's what the Drop trait is for, right? All you have to do is add whatever memory management code you'd have (in your C program) into the trait implementation and your memory deallocation will behave exactly as it would in any other low level language.

Great, but it doesn't guarantee any properties of code you haven't written, so it still can't achieve the global properties I've been talking about.

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

#399

Post by kbenson » Thu, Nov 17, 2016, 6:20 AM UTC

Animats wrote: post #257

kibwen wrote: post #22

Earlier quoted context omitted.

Speaking of HTTP clients, just yesterday the person behind Hyper announced their new high-level HTTP client crate: http://seanmonstar.com/post/153221119046/introducing-reqwest

Not sure what to think of that. Does everything have to be async I/O now? How often do you need massive numbers of client connections?

Simply put, IO as accessed by the Os is asynchronous by nature. The synchronicity you are used to is a nice artifact and lie the OS tells you to make simple programming easier. Underneath, the OS is doing everything asynchronously, and just waiting until complete to return, otherwise we would be throwing away massive quantities of compute cycles waiting for IO to complete.

Why let the OS and other programs running at the same time reap all that benefit? You too can program such that while you would normally be waiting for IO and some other programs was utilizing the CPU, your own cycles can be used and you can be accomplishing so much more.

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

#400

Post by pron » Thu, Nov 17, 2016, 6:22 AM UTC

hinkley wrote: post #334

pron wrote: post #51

Earlier quoted context omitted.

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.

What other programming languages do you know of that have an 'absolutely amazing' GC implementation? Wouldn't you like that answer to be 'lots'? The Java team has worked a lot longer and a lot harder on this problem than pretty much everyone else, and even they hit a wall at 1GB. One that took a dreadfully long time to overcome (so long in fact, that it contributed to me being an ex Java developer)

Java has quite a few very good GCs, some in OpenJDK, some by Oracle, and one by Azul. Quite a few of them don't have a 1GB wall. They will become even better when Java finally gets value types and the GC won't have to work hard to do stuff it doesn't have to (this is why Go has decent GC performance even though its GC isn't very sophisticated). In any event, I don't see how Rust can make the work any easier. Coming up with that algorithm is 98% of the job.

Lots of languages do have good GC because they run on the JVM. OTOH, we don't know how hard it is to write similar kinds of applications in Rust. Good things take a while to get right -- Java has taken a while, and Rust has, too. It will be a while yet until Java has a GC that everyone likes, and it will be a while yet until Rust is fully fleshed out and its strengths and weaknesses understood. My personal opinion is that the two approaches are complementary, each being superior in a different domain.