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

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

#91

Post by naasking » Wed, Nov 16, 2016, 7:28 PM UTC

wyldfire wrote: post #3

> GC pause ... sufficiently low power hw .. cheap phone Yeah, but even high-powered hardware can take a "major" hit from a GC pause when your application is extremely latency sensitive. 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. EDIT: I mean to say that many of my colleagues who write realtime software…

> 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 collection in this case takes literally zero time, but it's pathological case is when all referenced data survives the current GC cycle, ie. proportional to live objects.

There's no free lunch!

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

#92

Post by sctb » Wed, Nov 16, 2016, 7:28 PM UTC

gutfuck wrote: post #44

I've literally seen you tweet at people to kill themselves and then delete it. Idk about any of this other stuff but you certainly can't claim that your hands are clean in all this.

We've banned this troll account. You can't create new accounts just to violate the guidelines.

We detached this subthread from https://news.ycombinator.com/item?id=12970047 and marked it off-topic.

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

#93

Post by tmzt » Wed, Nov 16, 2016, 7:29 PM UTC

steveklabnik wrote: post #61

tmzt wrote: post #49

Earlier quoted context omitted.

Would it make sense to have a cargo/rustc flag to disable unwrap and friends when building for production?

unwrap has legitimate use-cases, and it's not clear what "disable" it would be, as it changes the type of the thing it returns. You could write a lint to fail the build, if you want, I guess...

Right, it would likely use clippy but it would essentially be a --production target or profile, intended for builds where the binary will be run in production. And by 'and friends' I mean calls that panic for the same reason as unwrap, such as expect or ok.

The goal is to stop code from reaching production inadvertently, not to prevent all sources of panics.

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

#94

Post by sctb » Wed, Nov 16, 2016, 7:29 PM UTC

cryptrash wrote: post #34

shmerl wrote: post #29

Earlier quoted context omitted.

Huh? Did you mix it up with something else? Rust community is one of the best. And what's "dangerous and unstable" there?

Of course I didnt. Klabnik is practically a communist, lots of anti-American sentiments, etc. Pcwalton has been spamming HN for ages about rust. They're all terrible. I've heard rumors of memory vulns in rust as well.

We've asked you specifically not to do this, so we've banned this account.

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

#95

Post by pron » Wed, Nov 16, 2016, 7:30 PM UTC

deathanatos wrote: post #76

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.

> If you have the extra RAM and power for a GC, you don't need Rust for safety. It isn't just about memory; Rust's safety guarantees in combination with RAII also mean that other resources such as mutex locks, open files, etc. also get closed in a deterministic fashion. (I'd argue that this is quite important for locks, but I've ran into hard-to-debug bugs b/c files weren't being closed out until a GC got to them.) T…

I was referring to hinkley's idea for using Rust to write GCed VMs. As to other safety features, those are easily added to cheaper GCed languages. Memory is the hard bit, and if you can afford a GC, it is usually cheaper to just use one. As to RAM being costly, I think RAM is one of the few things that is getting very cheap relative to other resources, and GCs require less and less tuning; working hard to avoid a GC when you can afford one seems to me like the mother of all premature optimizations. But I see no point in debating the issue too much. Every company would make its own consideration about which approach is cheaper.

In any event, there are certainly very important use cases that simply cannot afford the power and RAM overhead required by a GC (again -- latency is not an issue; if you have the resources, there are cheap ways of getting extremely low latencies without doing away with a GC) and those use cases would benefit tremendously from a safe language.

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

#96

Post by z3t4 » Wed, Nov 16, 2016, 7:31 PM UTC

0xAA55 wrote: post #7

z3t4 wrote: post #2

when you can run javascript on a pebble watch it blurs the boundaries ... Want to concat an number and string ? JavaScript wont complain.

Want to make a fast application on a pebble and with actual type checking? C and Ada won't complain or blur your lines... http://blog.adacore.com/make-with-ada-formal-proof-on-my-wri...

And real programmers write in machine code. Want to get shit done ? Most systems now a day has more then 20kb RAM! Where do you draw the line between systems programming and non system programming ? And why not write some quick and dirty code in say JavaScript and then do what needs optimization in C/assembly ? Assuming you are not restricted to a CPU that cost less then a dollar. And where does Rust come in ?

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

#97

Post by pron » Wed, Nov 16, 2016, 7:32 PM UTC

takeda wrote: post #82

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.

Lack of extra RAM and power to run GC is not the problem. The problem is that GC makes code behavior not predictable.

That's not true in general. I've used realtime Java in a safety critical hard realtime application (running on a large server), with strong deadline guarantees (we're talking microsecond range). If you have the power and RAM to spare, the predictability issue is more cheaply solved with the approach I mentioned above (by cheaply I mean in terms of development costs; it is more costly than "plain" GC in terms of effort, but still cheaper than the Rust approach).

The only real cost of GC these days is RAM (and power).

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

#98

Post by Rusky » Wed, Nov 16, 2016, 7:32 PM UTC

naasking wrote: post #91

wyldfire wrote: post #3

> GC pause ... sufficiently low power hw .. cheap phone Yeah, but even high-powered hardware can take a "major" hit from a GC pause when your application is extremely latency sensitive. 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. EDIT: I mean to say that many of my colleagues who write realtime software…

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

Lifetimes are compile-time only and do not do any reference counting. So Rust has the same latency guarantees as C, for example.

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

#99

Post by naasking » Wed, Nov 16, 2016, 7:32 PM UTC

takeda wrote: post #82

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.

Lack of extra RAM and power to run GC is not the problem. The problem is that GC makes code behavior not predictable.

That's not true, some GC algorithms make code behaviour unpredictable. Real-time tracing GCs exist. Reference counting is GC too, but it too is unpredictable.

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

#100

Post by ehsanu1 » Wed, Nov 16, 2016, 7:32 PM UTC

enqk wrote: post #62

SkyMarshal wrote: post #39

Earlier quoted context omitted.

The name of the game for the software industry is to continually create better tools that systematically, inexorably reduce the attack surface of apps built with them. Haskell does this in an interesting way by quarantining all side-effect code into Monads and preventing data races with immutability. Rust does it by making memory errors and race conditions impossible via its ownership mechanism. Think of it as guider…

Nevertheless these language specific solutions are completely opaque to an end user. These are software developer centric. As an end user I cannot inspect how these were applied and therefore develop trust in the end product. There's always an element of trust at the root of running a piece of software on my machine. I wish I could quickly inspect and be sure that say, the audio engine that mozilla firefox is running…

Defects can heavily affect the security of your assets though - just preventing buffer overflow is a huge win there. It just isn't a full solution to the problem of security in general, and I don't know that any such thing could exist, whether at the programming language level or otherwise.