|
Deus Rex posted: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... ...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 gotta live on da edge" is literally the exact opposite of supporting a good, stable language ecosystem. Look Around You fucked around with this message at 07:31 on May 8, 2015 |
# ? May 8, 2015 07:27 |
|
|
# ? May 15, 2024 03:52 |
|
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 gotta live on da edge" is literally the exact opposite of supporting a good, stable language ecosystem. 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 |
|
Deus Rex posted: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. 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. e: I mean I understand that that's how stuff gets tested and proven to work and stuff, but the language has literally not had a stable release yet. I'd argue that getting stuff out for your first real release is probably more important for giving the language a base to grow on than using cutting edge features. I'll admit I don't follow PL development in general too closely, so maybe I'm wrong. I guess I'm wondering if running nightly releases for a language's 1.1 release is common when it hasn't actually released their 1.0 stable yet, and if it is, how often developers target the 1.1 nightly over the 1.0 (almost) stable. Look Around You fucked around with this message at 08:20 on May 11, 2015 |
# ? May 11, 2015 04:33 |
|
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 |
|
Hay guys 1.0 is out http://blog.rust-lang.org/2015/05/15/Rust-1.0.html
|
# ? May 15, 2015 18:13 |
|
I was blown away by the go tour. Succinct and to the point. Is there anything similar for rust?
|
# ? May 15, 2015 19:37 |
|
Rust By Example is in a similar style to the Go tour. There's also the Rust Book which a more traditional format.
|
# ? May 15, 2015 20:21 |
|
Bingo! That hit the spot. Thanks!
|
# ? May 15, 2015 20:40 |
|
Rothon posted:Rust By Example is in a similar style to the Go tour. There's also the Rust Book which a more traditional format. I'm kind of offended by hello world being implemented with a macro.
|
# ? May 16, 2015 11:40 |
|
MALE SHOEGAZE posted:I'm kind of offended by hello world being implemented with a macro. It allows format arguments to be verified by the compiler. You could write the string literal directly to the stdout writer if you wanted to, but it's much more common to just use println!. It's basically equivalent to doing code:
|
# ? May 16, 2015 18:09 |
|
Rothon posted:It allows format arguments to be verified by the compiler. You could write the string literal directly to the stdout writer if you wanted to, but it's much more common to just use println!. It's basically equivalent to doing I mean, I guess it comes down to whether a hello world implementation is meant to demonstrate idiomatic code or whether it's meant to give insight into how the language operates. The macro completely obfuscates whatever is going on there and as far as I know, it could be hiding java levels of boilerplate (which would be fine or even cool).
|
# ? May 16, 2015 19:25 |
|
Whether a macro is complicated or the function is complicated, it's still just as complicated. It's really fruity that they don't have a non-macro version, though, but probably that would operate on bytestrings and not unicode strings, or static-lifetime string slices or whatever the gently caress a string literal is.
|
# ? May 16, 2015 19:34 |
MALE SHOEGAZE posted:I'm kind of offended by hello world being implemented with a macro. To be fair, macros much better in Rust than they are in languages like C++. IMO Rust macros are sort of like C++ templates, in that they are often ugly internally but allow for seemingly magic functions that "just do" whatever a user wants them to do. sarehu posted:Whether a macro is complicated or the function is complicated, it's still just as complicated. It's really fruity that they don't have a non-macro version, though, but probably that would operate on bytestrings and not unicode strings, or static-lifetime string slices or whatever the gently caress a string literal is. You could do something like Rust code:
|
|
# ? May 16, 2015 19:59 |
|
MALE SHOEGAZE posted:I mean, I guess it comes down to whether a hello world implementation is meant to demonstrate idiomatic code or whether it's meant to give insight into how the language operates. The macro completely obfuscates whatever is going on there and as far as I know, it could be hiding java levels of boilerplate (which would be fine or even cool). it would require a stronger type system to have a function like printf with variable arguments and be fully type checked fully type safe printf is like the hello-world of dependent types, maybe 2nd to length indexed lists
|
# ? May 16, 2015 20:40 |
|
VikingofRock posted:To be fair, macros much better in Rust than they are in languages like C++. IMO Rust macros are sort of like C++ templates, in that they are often ugly internally but allow for seemingly magic functions that "just do" whatever a user wants them to do. Why do you need the unwrap() at the end?
|
# ? May 17, 2015 05:00 |
|
Apparently write() returns a Result<usize, Error>, and unwrap() will panic if the result wasn't a success. Also I get warning: unused result which must be used, #[warn(unused_must_use)] on by default if you omit it -- it doesn't mind that the usize returned by .unwrap() is ignored.
|
# ? May 17, 2015 05:49 |
|
Ah, that attribute is a bit like Go's required-use returns then.
|
# ? May 17, 2015 06:05 |
Gul Banana posted:Why do you need the unwrap() at the end? You don't actually need the unwrap()--but if you don't put it there, you get a warning because write() has a tag which says to warn if you don't handle the failure case. I chose to panic in failure with unwrap(), but I suppose if I wanted a strictly equivalent program to "Hello, World!", I could do one of two things:
I'm pretty sure both should work, but apologies if they don't. I'm phone-posting and the Rust Playground is very hard to work with on mobile.
|
|
# ? May 17, 2015 18:32 |
|
I get the impression the Rust people aren't really great communicators. For example, take the Rust by example that was just linked here. It's nice and all, but I keep getting thrown off track every other paragraph because of how they use (or misuse?) common terms in programming that doesn't quite agree with how most everyone else use them. Or maybe it's just sloppy use of the English language in general, with ambiguous semantics and half-finished statements. Example: code:
You could argue that this is not a major thing, but on the contrary I'd argue that this choice of words is a collossal red humpback being hauled back and forth across the welcome mat, and frankly it is negatively impacting my desire to cross it. Again: code:
More: quote:This formatting functionality is implemented via traits, and there is one trait for each argument type. The most common formatting trait is Debug, which handles cases where the argument type is left unspecified: {} for instance. Oh boy. So "argument types" is no longer the types of the arguments, I take it, as most of the "traits" refer to integer numbers in various bases which do not matter to the internal representation of an integer stored in memory. And why only one? Is the Rust formatting support like super-gimped compared to how most other languages do it, where you can commonly do things like -03.4d? And {} is when the argument type is left unspecified, which is handled by Debug, except it is handled by Display. Ugh: quote:Implementing fmt::Display for a structure where the elements must each be handled sequentially is tricky. The problem is that each write! generates a fmt::Result. Proper handling of this requires dealing with all the results. Rust provides the try! macro for exactly this purpose. So what does try! do? What does it "return"? What does it "continue"? What does it do that its absence doesn't? Does it explicitly silence errors? If so, why is it called try!? I'm sort of inquisitive when it comes to new languages and I've given Rust an eye-over a few times in the past, and this sort of thing where the documentation is more of a distraction than a help is not a new thing in Rust, but I must say that it turns me off. I cannot shake the feeling that this weird text is written by a weirdo whose weird ideas also have made it into the language. What do you guys think? Do you have a similar impression of Rust docs, or is it just me being whiny and/or dumb? And perhaps more importantly, is Rust good? Is it worthwhile learning it (why?) or is it just a weirdo language for weirdos?
|
# ? May 17, 2015 21:36 |
|
Karate Bastard posted:Example: "Consume" is entirely correct here. The thing you call prepend on is moved from and you can't use it again afterwards.
|
# ? May 17, 2015 22:16 |
|
Well yeah, in a sense, but the data is still there, accessible unchanged just one hop away, containerized if you will. Even less "consumed" than a wrapped function. Or am I missing something fundamental?
|
# ? May 17, 2015 22:23 |
|
When you read data from a stream and store it in a data structure, the data still exists in some form, but you can't get to it from the stream. Similarly, when you call list.prepend(5), the data previously stored in list still exists somewhere, but you can't get to it from list.
|
# ? May 17, 2015 22:51 |
|
I think the official docs are awful, and some of the surrounding media is bad too, and some random blog articles are good. It doesn't help that the language has been unstable, so a lot of older docs keep getting updated like Wikipedia. "Consume" is something you'll see C and C++ people use to refer to invalidating an object or pointer (in particular, taking ownership of it), the usage here is nothing new. (It's probably terminology used in other languages, like the way Lisp's (NREVERSE X) would be said to "consume" X, but I can at least testify to C/C++ usage.)
|
# ? May 17, 2015 23:00 |
|
Karate Bastard posted:"Consume"? Really? I see the code they put there, and for what that does, in my experience most people would just say "takes". Sure, I can maybe accept that "consume" could possibly maybe not quite mean what they use it for here, but for most people in programming (?) "consume" has mutable or destructive connotations, like sucking data from a stream for processing, making it inaccessible for other processors of data from the same stream; it is "consumed" like food and cannot be consumed like food again. code:
code:
I can't really argue with the rest of your points. But just to be clear... quote:So what does try! do? What does it "return"? What does it "continue"? What does it do that its absence doesn't? Does it explicitly silence errors? If so, why is it called try!? quote:I'm sort of inquisitive when it comes to new languages and I've given Rust an eye-over a few times in the past, and this sort of thing where the documentation is more of a distraction than a help is not a new thing in Rust, but I must say that it turns me off. I cannot shake the feeling that this weird text is written by a weirdo whose weird ideas also have made it into the language. I don't think you should conclude that the language is equally weird and haphazard, there's a lot more eyes on language features than on some quasi-third-part code example project and the people in charge of the compiler internals aren't the ones writing the docs in the first place (unfortunately?). I think it's a good language, you might not get much out of learning it if you aren't enthusiastic about writing code in no-GC-allowed environments. It does have its weird spots and the restrictiveness of the borrow checker is really frustrating, so ymmv. The good parts are pretty much variants+pattern matching and decent abstractions for low-level-ish stuff, but it's nothing that's gonna ~blow your mind~ like Haskell or whatever.
|
# ? May 17, 2015 23:11 |
|
Vanadium posted:I can't really argue with the rest of your points. But just to be clear... Seems less useful than if Result<> just behaved like a proper monad IMO.
|
# ? May 18, 2015 01:08 |
|
Jabor posted:Seems less useful than if Result<> just behaved like a proper monad IMO. It does.
|
# ? May 18, 2015 01:40 |
|
Rust is a language that I think is good, but it's also a language that I think would make a horrible first one, and learning it is much better served by doing than reading. You can make that last point for all languages, but in Rust especially a lot of language quirks like lifetimes and such are really opaque until you wrestle with the compiler and spend a couple hours on Google a few times. It's hard to get a feel for them with a tutorial that simply illustrates correct and incorrect lifetime parameters.
|
# ? May 18, 2015 01:47 |
|
Thanks for all the good points guys! I guess I'll find some toy problems to dick around with instead.
|
# ? May 18, 2015 11:22 |
|
Rust is taking heavy criticism on twitter for posting a "team" page that is apparently all dudes, mostly white, and one of the people organizing the Berlin usergroup is super frustrated now because all the negative publicity is making their job harder.
|
# ? May 18, 2015 21:59 |
|
Have them draw lots, the loser gets hormone therapy.
|
# ? May 18, 2015 22:02 |
|
Vanadium posted:Rust is taking heavy criticism on twitter for posting a "team" page that is apparently all dudes, mostly white, and one of the people organizing the Berlin usergroup is super frustrated now because all the negative publicity is making their job harder. I don't know what the fuss is about, they're clearly including gorillas on the team: https://github.com/nrc
|
# ? May 18, 2015 22:09 |
|
For a serious take on the matter, I'm loving tired of people coming in to a community from the outside and telling them they need to have more [race/gender/language/sexuality/etc]. Especially when that community is around an open source project that literally anyone can contribute to (assuming a decent contribution). Take this one person who replied to their team page tweet: https://twitter.com/rustlang/status/599272106656985088 quote:I've recently been learning and playing around with Rust, but have been severely put-off by total lack of women. Maybe if you contributed to the project rather than bitching about the lack of women, there might actually be some women working on the language. Also, why the hell does the makeup of the core team matter for a programming language, which has primarily technical benefits and not social ones? The only actual barrier to entry I can see for Rust contribution is the English language. But it's not like Rust is alone or even significant in that regard.
|
# ? May 18, 2015 22:28 |
|
People often find it off-putting to be in groups where they feel little commonality. The tweet you quote is describing the poster's feeling, not telling anyone else they need to do something differently.
|
# ? May 18, 2015 22:41 |
|
Subjunctive posted:People often find it off-putting to be in groups where they feel little commonality. The tweet you quote is describing the poster's feeling, not telling anyone else they need to do something differently. Kathryn Long @StarKat99 May 15 posted:I'm glad you're aware of it but I think you need to get some specific plans to improve out there sooner rather than later the longer it goes unaddressed, the harder it will be to fix. And I know I'm not the only one that is going to wait and see until there's some definitive efforts of outreach and not just promises and plans
|
# ? May 18, 2015 22:45 |
|
Like there isn't plenty of nerds who'd look at an open source project 100% run by women and go "lol i'm not getting near that, this is clearly for girls, i'm not a girl". I don't think it's too farfetched that an all-guys lineup is offputting to women, which obviously isn't ideal for adoption of the language. In an ideal world the gender of the people organizing your open source community wouldn't matter. In this fallen world we live in, even the most well-meaning guys tend to turn out to be total goons and antagonize women for no good reason if left to their own devices.
|
# ? May 18, 2015 22:57 |
|
Rust's team is very open and welcoming to the point were they kicked a guy out for being too spicy. It's a shame they get blamed for what is an industry-wide problem. Now that I think about it what language design team actually have a woman in it?
|
# ? May 18, 2015 23:07 |
|
Shinku ABOOKEN posted:Now that I think about it what language design team actually have a woman in it? Sara Golemon on Hack, for one.
|
# ? May 18, 2015 23:16 |
|
Shinku ABOOKEN posted:Rust's team is very open and welcoming to the point were they kicked a guy out for being too spicy. I haven't followed Rust too closely, but didn't that guy have repeated and intense arguments with the core developers? Seemed like more a case of open personality conflict than being "too spicy".
|
# ? May 18, 2015 23:32 |
|
Redmark posted:I haven't followed Rust too closely, but didn't that guy have repeated and intense arguments with the core developers? Seemed like more a case of open personality conflict than being "too spicy". His arguments were technical as far as I recall.
|
# ? May 18, 2015 23:35 |
|
|
# ? May 15, 2024 03:52 |
|
strcat's technical arguments seemed to take the shape of "here's the right way to do it, i don't see why you'd possibly want to do anything else, clearly you aren't really invested in making rust a good language" every time, I can see how people got pissed off at that. I mean he was still right a lot of the time, but somehow that didn't help his case after a while.
|
# ? May 18, 2015 23:41 |