|
They didn't kick him out, they acted passive-aggressively towards him until he stopped contributing. After he left, a certain contributor would close issues that he'd opened with bothering to understand them, giving reasons that didn't actually engage with the issue. With Rust, it's like, instead of just disagreeing with you, a core team member will pop in and insinuate that you're lying. Edit: Basically me : Rust :: michaelochurch : VC's sarehu fucked around with this message at 02:27 on May 19, 2015 |
# ? May 19, 2015 00:29 |
|
|
# ? May 4, 2024 13:24 |
|
a person can be both right and also a giant dick in how they convey their message. the latter does not excuse the former also lmao at your garbage hn posts shrughes
|
# ? May 19, 2015 04:42 |
|
Suspicious Dish posted:a person can be both right and also a giant dick in how they convey their message. the latter does not excuse the former Do you mean the former doesn't excuse the latter? I agree that the official documentation (or at least "the Book", I can't speak for API docs) is pretty awful. It's written in a conversational style that just feels condescending to me. A few very smart and experienced programmers I know have been put off learning Rust until something like an O'Reilly book is released, because "the Book" is hard to follow, full of weird examples, and sometimes even hard to follow. What's frustrating is that pull requests like these, which do nothing but improve the clarity of a passage, were rejected because the primary docs author refused to accept style input. https://github.com/rust-lang/rust/pull/19929 https://github.com/rust-lang/rust/pull/20439 rust-by-example exists and is much better, but it's hardly a way to learn the language ex nihilo, in my opinion.
|
# ? May 21, 2015 08:07 |
|
Deus Rex posted:Do you mean the former doesn't excuse the latter? Rust is what happens when you let a bunch of Ruby developers design and document a language (José Valim being an exception) so it's not surprising that they're smug assholes who don't take criticism well. I'm in agreement with you that the conversational tone of "the Book" as it is referred to is dumb. I haven't looked extensively at the documentation in a while but the last I remember it was badly organized, but that may have also been because of the lack of clarity about crate usage at the time.
|
# ? May 21, 2015 14:39 |
|
triple sulk posted:Rust is what happens when you let a bunch of Ruby developers design and document a language (José Valim being an exception) so it's not surprising that they're smug assholes who don't take criticism well. I'm in agreement with you that the conversational tone of "the Book" as it is referred to is dumb. I haven't looked extensively at the documentation in a while but the last I remember it was badly organized, but that may have also been because of the lack of clarity about crate usage at the time. Out of the many prominent contributors and members of the "core team", I can think of two who are well-known "Ruby programmers". One of them is (was?) paid by Mozilla to work exclusively on documentation and the other was contracted by Mozilla to write the first version of the current incarnation Cargo (which was taken over by superhuman Mozillian acrichto pretty quickly), and now is a non-paid contributor assigned to work on tooling. The first one is the person who didn't accept pull requests on the basis of style; nobody else objected to it because they generally didn't make the quality of documentation their concern after he was contracted. I don't know where you get, like, "a bunch of Ruby developer" from. thestinger/strcat is like the anti-Ruby developer, and he designed practically half of the (good parts) of Rust. The quality of the introductory and API documentation is probably a blind spot for almost all of the primary contributors to the language and standard libraries, because they already know those things without needing to read the docs (plus they're so busy and whatever). It sounds like with 1.0, and a whole lot of new eyes, the documentation came under more scrutiny and hopefully there will be some improvements in tone and style.
|
# ? May 22, 2015 07:36 |
|
You don't have to tone police the docs, thank you.
|
# ? May 22, 2015 08:05 |
|
I did some rust this weekend and I will feel pretty convinced that it's going to be a big deal. I know you were all anxious to get my opinion so there it is.
|
# ? Jun 14, 2015 19:42 |
|
MALE SHOEGAZE posted:I did some rust this weekend and I will feel pretty convinced that it's going to be a big deal. Quick pick a top library from another language and then write it in Rust! Parsec, lens, an xml parser or something.
|
# ? Jun 14, 2015 20:24 |
|
Do they have a commonly used quickcheck yet?
|
# ? Jun 14, 2015 20:26 |
|
Shinku ABOOKEN posted:Now that I think about it what language design team actually have a woman in it? Ingela Andin and Siri Hansen on the erlang team.
|
# ? Jun 15, 2015 00:16 |
|
gonadic io posted:Quick pick a top library from another language and then write it in Rust! Parsec, lens, an xml parser or something. This maybe isn't a bad idea if you want 15 minutes of programmer fame.
|
# ? Jun 15, 2015 00:23 |
|
the talent deficit posted:Ingela Andin and Siri Hansen on the erlang team. Sara Golemon on Hack.
|
# ? Jun 15, 2015 01:25 |
|
So what's the best way to install Rust on OSX and get something half portable? Just the official installer? Hand-bomb the official binaries somewhere?
|
# ? Jun 19, 2015 00:13 |
|
I'm trying to learn some Rust since it seems like a pretty rad idea, so far I've been trying to do some simple data structures to figure it all out. Here's what I have for a binary search tree, it compiles and runs but the insertion doesn't fully work -- it seems to remove all the past changes each time you insert a new node: http://is.gd/qhiZkq code:
code:
Also how far off base is everything I did idiomatically-wise? Also what exactly is 'self.left.take()' doing? It fails compiling without it with the message 'cannot move out of borrowed content' and I somehow googled my way in to using it. edit: alright well scratch why it doesn't work, take() just replaces the content with a None, which is why my children are disappearing. How do I borrow the self.left and self.right in the match otherwise?
|
# ? Jun 19, 2015 05:24 |
|
piratepilates posted:I'm trying to learn some Rust since it seems like a pretty rad idea, so far I've been trying to do some simple data structures to figure it all out. I'm quite new to Rust myself so I spent some time wrestling the borrow checker, but the following works: (http://is.gd/nVAEU0) code:
code:
|
# ? Jun 19, 2015 17:36 |
|
^^^ pretty much the conclusion I came to. I'm also a Rust newb. You can also match on self and do roughly the same thing but it's very unwieldy.
|
# ? Jun 19, 2015 19:24 |
|
I'm basically know nothing about rust, but is there any way to "hide" mutability of a struct?code:
Also is there any long winded explanation of lifetimes, I'm an idiot and need more words
|
# ? Jun 19, 2015 19:54 |
|
Sweeper posted:I don't want to declare every object as mutable because a map it contains is mutable. I'd like to hide that implementation detail from the consumer... If you're doing something that modifies your object, you're going to need it to be mutable. This is by design. Having a function that modifies your object out from underneath you despite only taking a read borrow would defeat the entire purpose of the borrow checking and blow all of those safety guarantees out of the water. Whether a function changes an object isn't an "implementation detail" to be hidden away, it's an inherent part of the contract of that function.
|
# ? Jun 19, 2015 20:34 |
|
Gaukler posted:I'm quite new to Rust myself so I spent some time wrestling the borrow checker, but the following works: (http://is.gd/nVAEU0) Sounds good to me, thanks.
|
# ? Jun 19, 2015 23:58 |
|
Also, I think the more "Rustic" way is to use an enumerated type instead of a faux-null-pointer optioncode:
|
# ? Jun 20, 2015 00:08 |
|
I also wouldn't mind seeing more words about lifetimes. The official book is pretty brief about them. Like, both of these work:code:
code:
|
# ? Jun 20, 2015 00:15 |
|
Jsor posted:Also, I think the more "Rustic" way is to use an enumerated type instead of a faux-null-pointer option I don't think there's anything wrong with Option<Box<...>>. It's fairly common and compiles down to a potentially-null pointer, and it saves you the allocations. Sweeper posted:I'm basically know nothing about rust, but is there any way to "hide" mutability of a struct? Jabor posted:If you're doing something that modifies your object, you're going to need it to be mutable. This is by design. Having a function that modifies your object out from underneath you despite only taking a read borrow would defeat the entire purpose of the borrow checking and blow all of those safety guarantees out of the water. There's a lot of head-wrapping-around to be done with Rust in terms of how it straight-up doesn't let you structure some programs like it'd be the right way in millions of other languages. People on irc tend to scold me when I'm all "but that makes everything ugly and terrible and now I need to pass my state around explicitly like some sort of caveperson", and somehow it never seems to be a problem for all those clever things people do in Rust but I don't really get it. That said you can use RefCell to move the safety guarantees to dynamic checks instead, that should work here. rrrrrrrrrrrt posted:What the heck is the difference? Would you ever actually need more than one explicit lifetime for a struct? I think in both cases the struct itself is effectively restricted to the intersection of the two lifetimes, and I think it's fairly uncommon to have two lifetime parameters on a single type. But if you want to get one of the references out of the struct again, there's a difference in whether you've coerced both of them to the same intersectional lifetime. Your example isn't too helpful there because your string literals have static lifetime either way, so let's assume a Butt with two integer reference fields instead, then the following would only work with the Butt with separate lifetimes: code:
Vanadium fucked around with this message at 09:16 on Jun 20, 2015 |
# ? Jun 20, 2015 09:01 |
|
Vanadium posted:Do they have a commonly used quickcheck yet? Yes. https://github.com/BurntSushi/quickcheck
|
# ? Jun 20, 2015 09:27 |
|
quote:Rust 1.1 stable provides a 32% improvement in compilation time over Rust 1.0 (as measured by bootstrapping). quote:Benchmark compilations are showing an additional 30% improvement from 1.1 stable to 1.2 beta I was fairly excited about this like an hour and a half ago when I started building rust from source, not so much now
|
# ? Jun 25, 2015 21:35 |
VikingofRock fucked around with this message at 09:20 on Jul 3, 2015 |
|
# ? Jul 3, 2015 00:54 |
|
Can somebody please help me figure out how to do a tree traversal in a loop rather than recursively? The recursive version is blowing up my stack. The recursive code is essentially: code:
code:
code:
Specifically, it says the problem line is a mutable borrow at the line I call tree.act, which is where it borrows the tree's child out of the node's state->child hash map. Any ideas? I can't do this recursively because unfortunately it overflows the stack due to the depth of the state space. (I'm running monte-carlo tree search on Space Invaders). I can depth limit it, of course, but even if I do that I'll be able to go deeper if I can unroll this.
|
# ? Jul 24, 2015 06:59 |
|
It turns out the answer was "use Rc<RefCell<blah>>". That was a fun, if somewhat frustrating, adventure. I eventually went back to the recursive code because it turns out the iterative code had almost no benefit -- the stack overflows at pretty much the same point whether I'm using a homebrewed stack or a recursive one, which I definitely didn't expect!
|
# ? Jul 30, 2015 22:30 |
|
Jsor posted:It turns out the answer was "use Rc<RefCell<blah>>". That was a fun, if somewhat frustrating, adventure. I eventually went back to the recursive code because it turns out the iterative code had almost no benefit -- the stack overflows at pretty much the same point whether I'm using a homebrewed stack or a recursive one, which I definitely didn't expect! Yeah, the shittiest part of learning Rust is hammering nails into your dick trying to write data structure stuff. It's trivial in other languages, but writing them in (safe) Rust requires a decent understanding of its complex memory model, so it's a pretty bad place to start off. Rc and RefCell are usually enough to cover the gaps the borrow checker can't handle if you're cool with the overhead associated with them. If you're not, or you have a situation that's difficult to solve in safe Rust (doubly-linked list is one), don't be afraid to drop to unsafe{} . The standard library (which is written in Rust) uses it extensively.
|
# ? Jul 31, 2015 09:20 |
Speaking of unsafe Rust, there's a new Book in progress which covers it extensively.
|
|
# ? Jul 31, 2015 15:50 |
|
unsafe {} doesn't mean the code within is not safe; rather, it means that the memory safety of the block is promised by the programmer, instead of the compiler. The programmer might be wrong, of course. If you are trying to do something that you know is fine, but the compiler isn't smart enough to prove, that's exactly when you should be using unsafe {}. But it's probably wiser to implement it in such a way that the compiler doesn't need to trust you, wherever possible.
|
# ? Jul 31, 2015 16:48 |
|
Bongo Bill posted:unsafe {} doesn't mean the code within is not safe; rather, it means that the memory safety of the block is promised by the programmer, instead of the compiler. The programmer might be wrong, of course. If you are trying to do something that you know is fine, but the compiler isn't smart enough to prove, that's exactly when you should be using unsafe {}. But it's probably wiser to implement it in such a way that the compiler doesn't need to trust you, wherever possible. Hmm, that's an interesting way to look at it. The language is essentially a constructivist proof in terms of safety, in which parts of the program have two possibilities as far as the compiler is concerned: safe or unproven. When the borrow checker fails something, it's because it can't prove it's safe (rather than proving it unsafe), and the unsafe block tells it that its unprovability is okay. I'd avoided unsafe except for FFI code, but thinking of it that way makes it a bit more palatable to use it when I'm sure something is safe. Though I would imagine that unsafe also prevents it from passing noalias metadata to LLVM in some cases (though the code may still likely be faster than Rc<Refcell<T>>).
|
# ? Aug 1, 2015 02:04 |
I've been dicking around with Rust 1.0 recently and started fiddling with some Project Euler exercises. One thing that has been biting me is this: at times I'd like to use a variable x as a usize and other times as u64. In this case, I have one function which builds a sieve for the sieve of aristophanes (Vec requiring a usize) and another which does a multiplication into this requiring a u64. Is there an idiomatic way in Rust to use a numeric type, or am I attacking this from entirely the wrong angle?
|
|
# ? Oct 10, 2015 00:55 |
|
Jo posted:I've been dicking around with Rust 1.0 recently and started fiddling with some Project Euler exercises. One thing that has been biting me is this: at times I'd like to use a variable x as a usize and other times as u64. In this case, I have one function which builds a sieve for the sieve of aristophanes (Vec requiring a usize) and another which does a multiplication into this requiring a u64. Is there an idiomatic way in Rust to use a numeric type, or am I attacking this from entirely the wrong angle? You can do a type conversion with (x as usize), if you're on a 64-bit machine this is probably a no-op at runtime. Though it sounds like your multiplication function should probably be generic over the Mul trait. Unless you're multiplying by a constant. At the moment, unfortunately there's no good way to do generic arithmetic with any constants.
|
# ? Oct 10, 2015 01:03 |
Jsor posted:You can do a type conversion with (x as usize), if you're on a 64-bit machine this is probably a no-op at runtime. Though it sounds like your multiplication function should probably be generic over the Mul trait. All constants. I have two functions, one which finds the prime factors of a number (u64), and another which builds a sieve (which I'd use u64 for, but the array constructor requires usize). I'll see if I can copy my code over to this machine to share. I feel a bit bad using 'as usize' all over the place, but if there's no better way, I'll deal with it.
|
|
# ? Oct 10, 2015 01:08 |
|
Just throw type conversions around. IME it's pretty common, at least until associated constants become a thing. That or refactor the prime factor code to take a usize.
|
# ? Oct 10, 2015 01:18 |
|
1.5 is out and 'cargo install' seems pretty cool.
|
# ? Dec 19, 2015 13:43 |
Tarion posted:1.5 is out and 'cargo install' seems pretty cool. Agreed. It seems like Rust tooling is really taking off, which is very exciting to me.
|
|
# ? Dec 19, 2015 23:30 |
|
VikingofRock posted:Agreed. It seems like Rust tooling is really taking off, which is very exciting to me. Rust's runtime debugging really needs some work, though. If you have an erroneous `unwrap` you helpfully get the line number of the source code for Option it calls panic! on rather than the actual part of your code. This would be fine if RUST_BACKTRACE wasn't utterly useless on non-Linux systems, on my Windows machine it helpfully prints: code:
Gee, thanks, Rust, I learned so much. It's a good thing 98% of your Rust bugs the compiler catches, and 1.5% are logic errors that result in incorrect computations. Runtime panics happen so rarely this is at least tolerable. I can mostly get around it by always using expect instead of unwrap and making sure each possible panic has a unique error message.
|
# ? Jan 7, 2016 00:28 |
|
Jsor posted:Gee, thanks, Rust, I learned so much. It's a good thing 98% of your Rust bugs the compiler catches, and 1.5% are logic errors that result in incorrect computations. Runtime panics happen so rarely this is at least tolerable. I can mostly get around it by always using expect instead of unwrap and making sure each possible panic has a unique error message. You're not really supposed to use unwrap in 'production' code anyways.
|
# ? Jan 7, 2016 08:38 |
|
|
# ? May 4, 2024 13:24 |
|
Jsor posted:Rust's runtime debugging really needs some work, though. If you have an erroneous `unwrap` you helpfully get the line number of the source code for Option it calls panic! on rather than the actual part of your code. This would be fine if RUST_BACKTRACE wasn't utterly useless on non-Linux systems, on my Windows machine it helpfully prints: Yeah Windows debugger stack traces were working fine a little while back but ever since I upgraded to 1.4 beta and on it's been broken. Bit of a pain, unwrap isn't ideal and all but it's great for testing/prototyping. Tooling is definitely something Rust is lacking in at the moment. One of the Mozilla Rust guys lists his predictions for Rust in 2016. Better tooling is high up on that. Personally Visual Rust fully fleshed out would be a breaking point for me, decent IDE support and VS's debugger would be a multiplier on my productivity for sure.
|
# ? Jan 7, 2016 14:42 |