Live data from Hacker News

Rust and the Future of Systems Programming [video]

hacks.mozilla.org

81–90 of 511 posts

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

#81

Earlier quoted context omitted.

It would be in Rust too.

True enough. However, I'm willing to bet that a non-trivial amount of nightmarish code in C++ comes from the language itself. Also, I'm willing to be that a Rust build would be an improvement over a C++ build. As an example, I'm really sick of header files.

Maybe, maybe not. I think that you can write horrible code in any language (albeit horrible rust is safer than horrible C++ obviously). Especially considering the case when you're working on extremely compressed deadlines like many game shops, you're always in for a nightmare.

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

#82
post #51
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.

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

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

#83

I'll never use rust for anything important. Too dangerous, unstable, badly organized, toxic development community, the list goes on.

A lot of your attacks seemed to be aimed at personal beliefs of some of the rust developers. I follow some on twitter and they may have some views people disagree with, but nothing exceedingly controversial.

Furthermore, all other criticisms you've mentioned specifically towards rust and the community of rust are literal opposites of everything I've experienced.

The community is friendly and helpful. Rust is extremely stable, both as code, and as far as the developers making sure to not break backwards compatibility, going as far as testing EVERY PROJECT available in crates.io for regressions. They are also extremely organized, having all discussions in well thought out and documented RFCs,and allowing all to give input on it all.

I don't know what problems you have with Rust. I'm sure there valid things to critize. But everything you mentioned is categorically false. If you disagree, I'd be open to see proof of it all.

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

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

I do not tell people to kill themselves, as that's not cool. That said, I'm not interested in replying to brand new accounts made to troll me (and conveniently without evidence), so I won't be replying further.

He's obviously a troll or something. Keep up the good work, Steve! Rust's community is one of the most amazing and friendliest I've ever seen anywhere on the internet, and it seems to me that your intent, effort and presence is a significant part of that :) (Not to downplay any other people's contributions!)

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

#86
post #49
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?

If by "and friends" you mean "calls that can panic", there are a few of those. Slice bounds checks, for one.

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

#88

Earlier quoted context omitted.

It would be in Rust too.

True enough. However, I'm willing to bet that a non-trivial amount of nightmarish code in C++ comes from the language itself. Also, I'm willing to be that a Rust build would be an improvement over a C++ build. As an example, I'm really sick of header files.

Yes and no. Rust adds its own set of hassles. You think building becomes a synch? With Rust, you're fighting the compiler probably more than with C++. I'm sure some game developers would rather have an occasional crash they can fix down the road after their game is published than be forced to make a perfect system the first time. Remember, with game production, it's about time-to-market, not about perfect code.

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

#89
post #42

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

Rust doesn't need to stop C++ to be successful. The market for programmers is already large enough to successfully support dozens of programming languages, and that market will only continue to grow. PHP didn't "stop" Perl, Python didn't "stop" PHP, Ruby didn't "stop" Python, and yet all of these languages continue to be enormously successful. Why should we expect a monoculture on the systems side?

Python in my mind has supplanted perl, and ruby seems only to live on for the sake of Rails.

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

#90

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.

Not going to happen in the next 10 years, everything is built around C++. And tbh I don't see what would games benefit from using Rust instead of C++.
Post reply on HN