|
Shinku ABOOKEN posted:I toyed with Rust when it was 0.6~ and I am looking forward to trying it again. If you use vim or emacs, there's racer.
|
#
¿
Jan 19, 2015 12:26
|
|
|
|
| # ¿ Apr 28, 2024 23:56 |
|
|
sarehu posted:There's still aspects of the language that pay homage to concurrency, though, like how you can only have one mutable borrow at a time (if I'm not mistaken). This isn't really an homage to concurrency, it's required to safely implement things like a growable vector. If you could mutably borrow a Vec twice (or take out a mutable borrow while also borrowing it immutably), you could end up with a pointer to memory no longer owned by the Vec (like in the classic C++ case of appending to a std::vector while iterating over it). The language does still have some built-in nods to concurrency with things like the Send and Sync traits, which respectively mark types as being safe to send from one thread to another and mark types which can safely be aliased immutably from multiple threads.
|
|
#
¿
Jan 31, 2015 04:39
|
|
|
Jsor posted:Y'know, I think the worst thing about Rust is when the borrow checker can't prove something obviously safe is safe. If you have a function like fn get_something(&mut self) -> &mut MyType, and you match on self in the function, you absolutely cannot use any `ref`s on a pattern where you want to return self or Rust will refuse to acknowledge the borrow ends when the match is evaluated and the function returns. I don't think I understand your description of this particular problematic case, but in general yeah -- it can be very annoying when a borrow is held for much longer than it needs to, and you have to resort to scope convolution to satisfy the borrow checker. pcwalton had that huge patch to add "SEME regions" to later support non-lexical borrow scopes but it never landed, and I doubt anything like that will land before 1.0 :-\ Deus Rex fucked around with this message at 19:36 on Feb 27, 2015 |
|
#
¿
Feb 27, 2015 19:33
|
|
|
space kobold posted:I've got one dependency that only compiles on the 1.1 nightly, and another dependency that only compiles on the 1.0 beta. Welp. Guhh? What's the one that compiles on the beta but not the 1.1 nightly? That sounds like a regression that should be reported...
|
|
#
¿
May 8, 2015 07:18
|
|
|
Look Around You posted:...I don't understand why you would key your library off of a 1.1 nightly when you've got a 1.0 beta that's about to turn stable. Like, what's the point in targeting a (non 1.0) nightly at all right now? I could see coding for a nightly for an imminent upcoming release (say, when they're actually close to releasing 1.1), but they're targeting a nightly for a release that's slated for after the current, unreleased stable version. The entire point of making a stable 1.0 release is so that people have a set language+library to code against, and saying "naw gently caress that nightly 4 lyfe cuz There are a lot of interesting language features (compiler plugins) and library stuff that hasn't yet been stabilized. Off the top of my head, much of the Rust gamedev "ecosystem" uses some bleeding edge feature or another. And 1.1 is due to be released, what, 6 weeks after 1.0? Not that all of or even most of the current unstable stuff will be ready by then, of course. There aren't 1.0 nightlies anymore. Once they cut a beta, the nightlies bump to the next minor version. I wouldn't expect there to be nearly as much churn in future nightlies as there was in pre-1.0 nightlies (when broad syntax changes were still being made that broke pretty much every program). Anyway, my question was sort of the opposite of your concern, which is that in a 1.1 nightly there is apparently some regression that prevents a 1.0-beta library from building. If it's building on the 1.0-beta1 release, that's understandable because there were some breaking changes between beta1 and beta2, but if it builds on 1.0-beta2 and not 1.1-nightly there is a real problem that should be reported on GitHub.
|
|
#
¿
May 10, 2015 14:23
|
|
gotta live on da edge" is literally the exact opposite of supporting a good, stable language ecosystem.
|
Look Around You posted:No, I understand regressions being an issue that needs to be reported, I just don't get the mentality of using nightlies that way when you have a stable release coming out before the release that the nightlies are versioning to. Though if 1.1 is really slated for 6 weeks after 1.0 though, it's a bit of a different story and it makes a lot more sense. I tried finding a roadmap before I posted that (and just now as well), but I couldn't find one since they apparently took down the github wiki with their docs on it up and their forum doesn't seem to have one either... did they get rid of their mailing list too? I hadn't been following all that closely because I know 1.0 is right around the corner and didn't want to mess with too much before it hit. The nightlies have tons and tons more features and standard library APIs available to them than stable/beta does at the moment. I doubt that all of the projects currently targeting the nightly will migrate to a stable channel any time soon, because the features many of them depend on aren't close to being stabilized: compiler plugins (custom lints + syntax extensions), #![no_std] (for writing freestanding Rust, e.g. for a kernel), compiler internals, unboxed closure traits, reflection, thread locals, etc. probably won't be stabilized for many releases to come. Servo, which is definitely the largest Rust project, is probably never going to target a stable Rust release, because some of its purpose is to guide the language's further development. This blog post gives a good overview of the plan for releases, including an explanation of the purpose of each "release channel", although much of the specifics are now out of date: http://blog.rust-lang.org/2014/10/30/Stability.html This one covers a release timeline with dates: http://blog.rust-lang.org/2015/02/13/Final-1.0-timeline.html
|
|
#
¿
May 11, 2015 08:18
|
|
|
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
|
|
|
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
|
|
|
Vanadium posted:Do they have a commonly used quickcheck yet? Yes. https://github.com/BurntSushi/quickcheck
|
|
#
¿
Jun 20, 2015 09:27
|
|
|
Tarion posted:You're not really supposed to use unwrap in 'production' code anyways. Sure you are. Maybe not as much, or in all the same ways, as when you're hacking together a prototype, though.
|
|
#
¿
Feb 8, 2016 09:12
|
|
|
|
| # ¿ Apr 28, 2024 23:56 |
|
|
sarehu posted:Edit: On that note, is there any way to make a match pattern redundantly declare the type of a variable? Take for example The feature you're looking for is called "type ascription": https://github.com/rust-lang/rfcs/issues/354
|
|
#
¿
Aug 21, 2016 15:03
|
|