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

101–110 of 511 posts

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

#101

Post by q3r3qr3q »

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.

I'd get excited and go through some tutorial on their website, probably the main? tutorial, bu then when you get to the lifetimes section is seemed to get really complicated instantly. I tried twice and think I hit the same problem. Maybe some more good examples would help?

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

#102

Post by cbHXBY1D »

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.

Not specifically about your book, but I would love if there was a quicker way to find methods in the docs.

Right now, if I want to find the methods used by BTreeMap you have to wade through a good amount of information until you can find how to just get the keys. I'm currently on mobile where the issue is more prominent.

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

#103

Post by qwertyuiop924 »

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…

Rust itself can't, but you as the programmer can.

It's not quite C, but you can do a lot of reasoning about what the compiler will do with your code, and avoid pathological cases.

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

#104

Post by wyldfire »

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.

Consider Piston. Not able to compete with Unreal and Cry yet but it's a WIP.

[1] http://www.piston.rs/

[2] https://github.com/PistonDevelopers/piston

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

#105

Post by takeda »

user5994461 wrote: post #57
kibwen wrote: post #42

Earlier quoted context omitted.

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?

What's the place for Rust in the market? The distributed systems have already moved to Go (when it's not Java/C# :D). The system programming is done in either C or C++. (Depending on history and availability). The oldest stuff and/or most constrained is stuck with C. They're struggling to have anything moved over to C++. Rust is entirely out of question.

Rust overlaps with C/C++ and even with Go. Go was initially trying to be a replacement for C/C++, but hasn't succeeded, because it is too high level. Rust on the other hand looks very promising in that area, which requires low level access but also desires safety.

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

#106

Post by qwertyuiop924 »

shandor wrote: post #55
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. It would, and definitely should, move into the direction of safer languages than C. The biggest problem I see is tooling and legacy. Tooling, because there's a ginormous amount of testing and design software that "works with C" (whatever that means in the co…

I wouldn't hold your breath for C to die though. C sucks at many things, but it's pretty good in embedded, if you're not writing ASM.

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

#107

Post by wyldfire »

VoidAgent wrote: post #33

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

I love C++, for decades it was one of the only games in town. But IMO there's a huge pipeline stall in C++17.

Features postponed beyond C++17 related to or bound to C's legacy are already in Rust (modules, e.g).

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

#108

Post by wyldfire »

gcp wrote: post #84
user5994461 wrote: post #65

I'd like to see an analysis: "The amount of real world jobs available for Rust, in comparison to Ada." The numbers may be self explanatory.

What would they explain though?

They would explain Rust's relative youth and corresponding growth opportunity. ;)

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

#109

Post by qwertyuiop924 »

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/

Well, I'm an Emacs user. I don't necessarily care about the tools that more IDE focused people might (OTOH, RMS should loosen up on the AST: you can't afford to lose much more than you already have), but rust-mode works fine for me.

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

#110

Post by naasking »

Rusky wrote: post #98
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…

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

> Lifetimes are compile-time only and do not do any reference counting.

I never said they did, I said lifetimes and reference counting both have this pathological case.

C also doesn't provide latency guarantees, as the same pathological programs can exist in C as well. It's a total myth that you need C in realtime domains due to "latency".

Maximum pause times are a property of a particular runtime, not a language.

Post reply on HN