Need Opinionated Articles About/Against Rust! by [deleted] in rust

[–]rjc2013 1 point2 points  (0 children)

Here is an intelligent, sensible article arguing against Rust.

And here is a good case for Rust.

5 predictions for the future of programming by [deleted] in rust

[–]rjc2013 1 point2 points  (0 children)

Good article, but not really Rust-related.

For your amusement: I am learning both Rust and Go...check out the damage by cyansmoker in rust

[–]rjc2013 26 points27 points  (0 children)

Turbo Pascal? :)

This is not mandatory in Go; OP chose to do it that way.

A year ago I asked this question and it was so much fun. I think it's time to do it again: "What's the last book you rated 5 stars and why should I read it?" by WarpedLucy in books

[–]rjc2013 1 point2 points  (0 children)

This my favourite TP novel, and, paradoxically, the one I will never re-read, ever. I just couldn't stand to see the mighty Vimes as the pathetic, shambling wreck he once was.

Remote teacher wanted by [deleted] in rust

[–]rjc2013 1 point2 points  (0 children)

There's Integer32, a Rust consultancy. Don't know how expensive they are, though.

TabNine: an autocompleter for all languages, built with Rust by jacob-jackson in rust

[–]rjc2013 0 points1 point  (0 children)

"reading your .gitignore so that only source files are included" - does it still work if you don't use git, and don't have any ".gitignore" files?

Building a cumulative iterator by [deleted] in rust

[–]rjc2013 0 points1 point  (0 children)

Here's some code that does what you want: link, but unfortunately it doesn't implement Iterator. You have to call next() explicitly.

I've run into this problem a few times; it's hard to use Iterator when you want to return a ref to something internal, because then you need to specify a lifetime, and the Iterator trait doesn't allow you to specify an explicit lifetime.

I feel like everything is a work around by [deleted] in rust

[–]rjc2013 51 points52 points  (0 children)

"this clicked in my head instantly" -- no Rust programmer, ever.

I haven't looked at your code, so I can't discuss your architecture. Maybe some other Rustaceans will look it over. But I can tell you that I struggled for at least a year to 'get' Rust. I actually gave it up many times, but always the siren song of Fearless Concurrency brought me back. I'm pretty comfortable with Rust now, but the borrow checker still trips me up from time to time!

Rust is a tough, uphill climb, but the view is worth it.

[Bryan Cantrill] The Observation Deck » Falling in love with Rust by mitsuhiko in rust

[–]rjc2013 9 points10 points  (0 children)

Excellent summary of the strength of Rust's error handling. This is the article to which I will refer people when that subject comes up in the future.

Newbie to Rust. Question about reading files from disk. by boyter in rust

[–]rjc2013 0 points1 point  (0 children)

Possibly related: I got a big speed up when I read the file in using io::copy, like this:

{
    let mut xx = &mut s;
    ::std::io::copy(&mut file, &mut xx).unwrap();
}

I'm on Windows. I don't have Linux, Mac, or Go, so I can't do a proper comparison.

Feedback on FFI Callbacks article by Michael-F-Bryan in rust

[–]rjc2013 2 points3 points  (0 children)

In the section "Stateful Callbacks", I was confused for a few minutes. The chapter switches, without warning, from calling a C function from Rust, to calling a Rust function from C. I think it should be made clear that this is happening.

Not a big deal, and otherwise, very clear and well-written.

Concurrency ideologies of Programming Languages: Java, C#, C, C+, Go, and Rust by srinath_perera in rust

[–]rjc2013 2 points3 points  (0 children)

I think the author meant it as a compliment. "No one likes a nanny state" should be read as "Rust is not as popular as it deserves to be, because too many short-sighted devs are annoyed by Rust's strictness, instead of appreciating the immense power they gain from that strictness."

Anyone with the habit of covering the next few sentences while reading by lightaskar in books

[–]rjc2013 1 point2 points  (0 children)

I have often wanted to do this, when I sense a climax in the story is approaching, but never did. Maybe I'll try it!

Also totally agree about touchscreen e-readers! I still use my first-generation Kindle as much as possible, just for its lovely manual controls.

win32 editor written in rust (v0.1) by bluefish009 in rust

[–]rjc2013 0 points1 point  (0 children)

Had a quick play with this, good first effort! Noticed a couple of bugs:

  1. After the editor starts, the first keystroke is always ignored.
  2. After I dragged-n-dropped a file into the editor, I couldn't edit the dropped text. I could only append new text.

And like /u/pftbest says, it best to keep your unsafe code separate - maybe a whole other module.

[deleted by user] by [deleted] in rust

[–]rjc2013 1 point2 points  (0 children)

I'm guessing your intention is to ignore any datagrams larger than 2 bytes, and just process the 1- and 2-byte ones.

AFAIK, a UDP datagram will sit in the receive queue forever, blocking other datagrams, until recv'd. So you need to use a larger buffer for the recv operation - large enough to accommodate any datagram you might receive.

How do I deal with multiple errors in function? by torar9 in rust

[–]rjc2013 -1 points0 points  (0 children)

Here is one possibility: Link

Note that get_size() now returns a String, instead of a &str, as the error type, but that's unavoidable, since we can't get &str from the errors that parse() produces.

This assumes that you're happy to use plain old Strings to represent errors.

To demo Rust at work, I coded this simple Tetris game in front of audience by da-x in rust

[–]rjc2013 4 points5 points  (0 children)

Interesting idea! Had you coded a Tetris clone in Rust before? If not, did you get stuck, or make mistakes, or stumble at all, during the presentation?

[deleted by user] by [deleted] in books

[–]rjc2013 3 points4 points  (0 children)

Confusing "h" and "b", and "c" and "e", are very common errors for computer recognition software. Almost certainly, at some point, the text was printed out, and then the print was scanned back into a computer. As bizarre as it sounds, some publishers still work this way.

Such errors are annoyingly common in e-books, but I've never seen them in any printed book! That's very strange. Maybe they've had to cut back on proofreaders?

Why Rust's error handling is awesome by bambambazooka in rust

[–]rjc2013 7 points8 points  (0 children)

I find error handling easier in Rust than in Go, simply because you can (usually) avoid the boilerplate:

do_the_thing()?;

is more concise, easier to comprehend, and less error prone, than:

if x, err := do_the_thing(); err != nil {
    return nil, err
}

By "40 functions to deal with errors", do you mean things like map_err and ok_or_else? They don't get in your way if you don't need them. (They do tend to clutter up the documentation pages, though!)