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

61–70 of 511 posts

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

#61

Post by steveklabnik »

tmzt wrote: post #49
pimeys wrote: post #19

Now I have four services running on production, all written with Rust. If it compiles, it usually works. Of course you have these late night sessions where you write that one unwrap() because, hey, this will never return an error, right? And bam... I'm seriously waiting that tokio train to be stable and a unified way of writing async services without needing to use some tricks with the channels or writing lots of ugl…

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

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

#62

Post by enqk »

SkyMarshal wrote: post #39
enqk wrote: post #4

Although I am not against improving the safety of languages we use for system programming, the model that Rust advocates are pushing of "preventing mistakes" as a way to make systems secure doesn't convince me. Mistakes (and security breaches) happen. A system should be written in such a way as mistakes are few, indeed, however it is essential to also efficiently protect our users' assets (data) first, assuming that…

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 runs completly in a segregated zone/container/sandbox that will prevent, even in the presence of defects, its exploitation to leak data that is important to me.

I guess it's just a question of words and goals being a little bit too overlapping. Rust's approach is to address safety as in the rates of defects. However it does nothing, and probably cannot, address the security i.e. the impact on my own safety or that of my assets.

As an end-user I care much more about security than I care about defects.

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

#63

Post by thewhitetulip »

gcp wrote: post #43
VoidAgent wrote: post #33

IMO C++ is unstoppable now, c++ 11, 14 and 17 additions with GSL and all things in the pipeline ...

A project like Servo means that the proof will be in the pudding. Gecko and WebKit/Blink are C++ (though stuck at C++11 due to compiler and platform compatibility). So we'll see how they end up comparing.

I really wish that they replace Firefox with a browser written using Servo. That'll be fun.

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

#66

Post by steveklabnik »

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.

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

#67

Post by mordocai »

CodeMage wrote: post #56

I'd love to see someone write a game engine in Rust to compete with the "big boys" like Cry or Unreal. C++ game code can be such a nightmare.

Game code in general is usually a nightmare. I do think Rust would be better than C++ though, in a lot of ways.

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

#68

Post by Manishearth »

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

clippy has this already :)

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

#69

Post by vvanders »

harveywi wrote: post #64

The state of Rust editors continues to evolve [1], but I would be curious to learn more about the editors/IDEs that people are using for Rust development. Any stories or thoughts? [1] https://areweideyet.com/

VSCode + Racer have been working really well for me. Pretty decent auto-complete and integration.

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

#70

Post by [deleted] »

steveklabnik wrote: post #37
cryptrash wrote: post #34

Earlier quoted context omitted.

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.

I make it a strong point to keep my personal politics outside of Rust; there's actually many people who work within Rust and its community that I would fight bitterly with about politics, but we instead focus on the technology and work together in a productive manner. If you see me acting inappropriate within Rust project spaces, please report me to the moderation team: the core team is subject to moderation just lik…

[deleted]
Post reply on HN