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

261–270 of 511 posts

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

#261

Post by braveo »

leshow wrote: post #246
duneroadrunner wrote: post #226

Earlier quoted context omitted.

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…

Correct me if I'm wrong, but it looks like this just provides some 'safe' alternatives to unsafe C++ things. It's still up to the diligence of the programmer to not use those things and nothing is getting statically verified. By contrast, when I write Rust, memory safety (and type safety) are verified by the compiler.

Sometimes I think Rust people lose the forest for the trees. The end goal isn't for the compiler to verify the safety, the end goal is for the software itself to be safe in a way that's cheaper.

It doesn't really matter if they both end up at the same place, which is safe software.

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

#262

Post by hguant »

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/

Literally just started looking into Rust for use in production yesterday. I've been playing with it in two different editor.

SublimeText + Rust Enhanced has been really really awesome. In line error messages, fairly decent autocompletion (from what I've seen so far) - I don't really use full IDE's that often (vim is my go to) so this is what I imagine that feels like.

vim + vim-racer has been good. I use the `gd` command (go to definition) every now and then. I'm probably not getting the full use out of it.

I think my problem is that at the end of the day, it's a text editor and I don't have very high expectations. I want some syntax highlighting, I want curly brace and parenthesis matching, and I'd like to be able to change the font. Everything on top of that is gravy.

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

#263

Post by colemickens »

VoidAgent wrote: post #33

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

Except that even if you write perfect code and have a compiler that supports all of the features... you code still won't be as safe as it is if rustc signs off on it.

This conversation happens in literally every single thread about Rust. Every single time someone implies that new features in 14/17 will somehow make Rust irrelevant, but it's simply not true. There are classes of problems which Rust can catch which a C++ compiler cannot. And I don't really care about "if all devs wrote perfect code" because we get a new CVE every 3 weeks from some C/C++ codebase that has brilliant people working on them.

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

#264

Post by sidlls »

Skalman wrote: post #190
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

For me the hump was from the get-go. Following the book, I installed Rust directly, but then i realized that I should've installed it via Rustup. Next, I want a good editing environment, so I install VS Code and Racer, but then I find out that I can't use Clippy unless I use Nightly... and I'm not interested in using Nightly, so I'll wait.

I just installed the nightly tarball and used my usual editor (emacs). I'm not sure what the editing environment has to do with a learning hump.

Now, coming from loose dynamic typed languages or really terrible C or C++ code bases is another matter.

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

#265

Post by [deleted] »

Skalman wrote: post #190
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

For me the hump was from the get-go. Following the book, I installed Rust directly, but then i realized that I should've installed it via Rustup. Next, I want a good editing environment, so I install VS Code and Racer, but then I find out that I can't use Clippy unless I use Nightly... and I'm not interested in using Nightly, so I'll wait.

[deleted]

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

#266

Post by colemickens »

cryptrash wrote: post #28

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

I've had nothing but amazing experiences in the Rust community, and was actually proud/embarrassed the one time that I was chastised for being rude in /r/rust.

The Rust community reminds me of how welcoming the Go community used to be... (I love Go and write it every day, this isn't some sort of commentary about Go).

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

#267

Post by Matthias247 »

takeda wrote: post #105
user5994461 wrote: post #57

Earlier quoted context omitted.

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.

I wouldn't say Go hasn't succeeded. Maybe not as a general replacement for C/C++. But still lots of new applications that would most likely have been written in C/C++ a few years ago are now popping up in Go (unix daemons, commandline tools, ...).

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

#268

Post by steveklabnik »

Animats wrote: post #257
kibwen wrote: post #22

Earlier quoted context omitted.

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?

1. This introduces a primarily synchronous API for now. Async will come later. All those code samples are synchronous.

2. Async I/O is an extremely hot topic in Rust right now, so it's likely that Rust people do care about it.

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

#269

Post by naasking »

Manishearth wrote: post #244
naasking wrote: post #240

Earlier quoted context omitted.

> You can probably make this work by plugging in a different allocator, if jemalloc doesn't do this already. The ability to batch up frees and mallocs isn't tied to GCs. That gets tricky, because Rust people no doubt expect deterministic destruction on scope exit. But yes, my ultimate point is that low latency is a property of a runtime, not a language. C/C++ or Rust aren't going to automatically give you bounded lat…

> Rust people no doubt expect deterministic destruction on scope exit. Deterministic destruction, but not deterministic deallocation :)

But this expectation is transitive. If you have an array of file handles, if you defer deallocating some of them but destruct them all upfront, you still have the latency issue we've been discussing. And if you defer destructing too, then you still have non-deterministic destruction and deallocation. I'm not sure there's a way around this tradeoff.

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

#270

Post by papaf »

steveklabnik wrote: post #254
papaf wrote: post #248

Earlier quoted context omitted.

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

Thanks, thats very helpful. I did not know about the minus sign.

A polite suggestion - maybe the link marked [-], that takes you to the index, could be labelled "index".

Post reply on HN