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

251–260 of 511 posts

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

#251

Post by bquinlan »

shriek wrote: post #143
steveklabnik wrote: post #66

Earlier quoted context omitted.

How are you trying? What are you getting stuck on? I'd love to improve things.

I'm also in a similar boat but my primary thing being that I learn by doing and since it's branded as "system programming" I immediately think of big projects like kernels and drivers. I wish there were some small projects that I could do apart from just doing "project euler" that would be helpful to me. I even bought raspberry pi to learn rust but don't quite know what to do with it and rust.

This might be too much like Project Euler but I started by solving some common interview problems using Rust.

Try solving the problems without looking at the solutions first: https://github.com/brianquinlan/learn-rust

Here is a rough rank of difficultly: https://github.com/brianquinlan/learn-rust#understandability

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

#252

Post by pcwalton »

duneroadrunner wrote: post #226
pcwalton wrote: post #173

Earlier quoted context omitted.

"Safer C++", like all C++ template libraries, is not memory safe.

Are you confusing SaferCPlusPlus with a different library? SaferCPlusPlus is a new library that makes it practical to stick to a memory safe subset of C++ (i.e. no native pointers, no native arrays, no std::array , no std::vector , etc.). Using the SaferCPlusPlus library to replace all uses of C++'s unsafe elements does result in code that is as memory safe as Rust, or any other modern language. The main shortcoming…

Create a vector. Push an element onto it. Take a reference to that element with operator[]. Clear the vector. Call a method on that dangling reference.

Create an object on the stack. Return a reference to that object. Call a method on that reference.

Create a vector. Push an element onto it. Call a method on that element that clears the vector and then calls another virtual method on itself, via the this pointer.

Accidentally share a vector between threads. Race push_back() and remove().

Etc. etc. We didn't implement lifetimes for no reason.

Additionally, the pointer registration mechanism that that library uses has a runtime performance cost worse than a GC write barrier (because it incurs writes on reads).

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

#253

Post by z3t4 »

wyager wrote: post #211
z3t4 wrote: post #113

Earlier quoted context omitted.

foo = (string, number) => string + number Now go write that in your preferred language!

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"

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

#254

Post by steveklabnik »

papaf wrote: post #248
steveklabnik wrote: post #66

Earlier quoted context omitted.

How are you trying? What are you getting stuck on? I'd love to improve things.

What are you getting stuck on? I'd love to improve things. I feel I am getting over the hump of learning rust now and coding in rust is becoming less frustrating for me. However, one thing that slows me down is the lack of indices in the documentation. For instance, if I want to know the return type of a vector len() I go here: https://doc.rust-lang.org/std/vec/struct.Vec.html .. and then I have to search the web pag…

Two things:

If you click the little [-] button, you'll get an index for that page.

If you use the search bar at the top, https://doc.rust-lang.org/std/vec/struct.Vec.html?search=vec... will let you go right to the method. (In this case, you have to know that it's slice::len though)

Does that help?

EDIT: UX is hard! Glad people are discovering this. It's the same symbol HN uses, incidentally...

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

#255

Post by nickpsecurity »

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.

Real-time GC's exist. Look up Aonix's Java stuff for what embedded or predictable apps do. Or JamaicaVM below. For enterprise, Azul has some amazing GC tech plus Java CPU's (Vega's).

http://www.ptc.com/developer-tools/perc

https://www.aicas.com/cms/en/JamaicaVM

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

#256

Post by nickpsecurity »

pron wrote: post #97
takeda wrote: post #82

Earlier quoted context omitted.

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

Which VM did you use for that out of curiosity?

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

#257

Post by Animats »

kibwen wrote: post #22
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…

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?

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

#258

Post by leshow »

Narann wrote: post #154
leshow wrote: post #9

Rust is great. I've been following it since pre-1.0 and writing code with it for about as long also. It's really come a long way, my favorite language for pretty much anything except web development.

Wow! You've got my attention! I mean, I feel many rust stuff (crates/dev/tools) seems to focus on high performance web so, as a low level guy enjoying bitwise ops and dynarec stuff I was wondering if rust what a good thing for me or if it would be better to stick in C. Can you tell me which kind of project you do in rust, what was your original language and why rust shine compared to your previous language?

I started on Java in school for software eng. After that I did a lot of front and backend development in dynamic languages and forgot all about types.

Until I discovered Haskell and saw what a really powerful type system can do. Rust's type system is very very similar to haskell's if you substitute the word 'trait' for 'typeclass'. However code is imperative, so that's nice for some applications, and is faster/lower level.

I've used the crate nom (https://github.com/Geal/nom) in the past, it's a parserc library for consuming bits/bytes. I used it to write a function that consumes a vector of unsigned bytes, 11 bits at a time. If you're interested in that sort of stuff, take a look for yourself and see if you like it.

As with most things in Rust nom generates parsers with little to no runtime overhead, so you pay nothing for the increase ergonomics.

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

#259

Post by lacampbell »

fuine wrote: post #216
lacampbell wrote: post #181

Earlier quoted context omitted.

Not OP, but as someone who theoretically would like Rust - I'll bite. Maybe my usecase is a common one. I understand memory management in C. I understand it modern C++ (destruction when going out of scope, smart pointers etc). Basically, a description and discussion of borrow-checking for people who have already used system programming languages would be really helpful. I feel like the book is targeting people who ha…

Have you tried looking at https://github.com/nrc/r4cppp ?

That looks like exactly what I'm after actually. I'll read this next time I try rust.

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

#260

Post by Matthias247 »

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.

However that's not something that is automatically solved by manual memory management. Using malloc/free on a desktop OS does also not provide a predictable runtime behavior, although unexpected pauses might be smaller than with most GCs.

The safest bet for predictable memory management and latency is the approach that is used by lots of embedded and realtime software: Don't allocate at all. Or at least don't do it in critical phases.

Post reply on HN