Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Look Around You
Jan 19, 2009

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 :rice: 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

Adbot
ADBOT LOVES YOU

Deus Rex
Mar 5, 2005

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

Look Around You
Jan 19, 2009

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.

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.

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

Deus Rex
Mar 5, 2005

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

Vanadium
Jan 8, 2005

Hay guys 1.0 is out http://blog.rust-lang.org/2015/05/15/Rust-1.0.html

Karate Bastard
Jul 31, 2007

Soiled Meat
I was blown away by the go tour. Succinct and to the point. Is there anything similar for rust?

Rothon
Jan 4, 2012
Rust By Example is in a similar style to the Go tour. There's also the Rust Book which a more traditional format.

Karate Bastard
Jul 31, 2007

Soiled Meat
Bingo! That hit the spot. Thanks!

DONT THREAD ON ME
Oct 1, 2002

by Nyc_Tattoo
Floss Finder

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.

Rothon
Jan 4, 2012

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:
#include <stdio.h>

int main() {
    printf("hello, world!\n");
}
in C, except that compilation will fail if you accidentally put a format specifier in the string instead of maybe warning and reading some trash off the stack.

DONT THREAD ON ME
Oct 1, 2002

by Nyc_Tattoo
Floss Finder

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
code:
#include <stdio.h>

int main() {
    printf("hello, world!\n");
}
in C, except that compilation will fail if you accidentally put a format specifier in the string instead of maybe warning and reading some trash off the stack.

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

sarehu
Apr 20, 2007

(call/cc call/cc)
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.

VikingofRock
Aug 24, 2008




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:
fn main() {
    use std::io::Write;
    std::io::stdout().write("Hello, world!".as_bytes()).unwrap();
}
if you wanted, but IMO the macro version is simpler, easier to understand, and more idiomatic, so it makes sense that they would put it in the "Hello, world!" example.

Malcolm XML
Aug 8, 2009

I always knew it would end like this.

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

Gul Banana
Nov 28, 2003

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.


You could do something like

Rust code:
fn main() {
    use std::io::Write;
    std::io::stdout().write("Hello, world!".as_bytes()).unwrap();
}
if you wanted, but IMO the macro version is simpler, easier to understand, and more idiomatic, so it makes sense that they would put it in the "Hello, world!" example.

Why do you need the unwrap() at the end?

sarehu
Apr 20, 2007

(call/cc call/cc)
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.

Gul Banana
Nov 28, 2003

Ah, that attribute is a bit like Go's required-use returns then.

VikingofRock
Aug 24, 2008




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:

  1. Explicitly tell the compiler to ignore the warning by tagging the main function with #[allow(unused_must_use)]
  2. Explicitly tell the compiler to ignore the result, by writing

    Rust code:
    
    fn main() {
        use std::io::Write;
        let _ = std::io::stdout().write("Hello, world!".as_bytes()).unwrap();
    }
    

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.

Karate Bastard
Jul 31, 2007

Soiled Meat
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:
    // Consume a list, and return the same list with a new element at its front
    fn prepend(self, elem: u32) -> List {
        // `Cons` also has type List
        Cons(elem, Box::new(self))
    }
"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.

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:
    // but public structs with private fields can't be constructed
    // Error! `BlackBox` has private fields
    //let black_box = my::BlackBox { contents: "classified information" };
    // TODO ^ Try uncommenting this line

    // However, structs with private fields can still be created using
    // constructors
    let _black_box = my::BlackBox::new("classified information");
So public structs with private fields can't be constructed but can still be created using constructors. Really? (Yes, after rereading the code a few times I realize it really does what I assumed it would do, and structs work the way I assumed they would work, and those comments are just whale dragging).

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.
...
Here's the full list of formatting traits and their respective argument types:

unspecified -> Display
? -> Debug
o -> Octal
x -> LowerHex
X -> UpperHex
p -> Pointer
b -> Binary
e -> LowerExp
E -> UpperExp

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.

Using try! on write! looks like this:
code:
// Try `write!` to see if it errors. If it errors, return
// the error. Otherwise continue.
try!(write!(f, "{}", value));

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?

Plorkyeran
Mar 22, 2007

To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Karate Bastard posted:

Example:
code:
    // Consume a list, and return the same list with a new element at its front
    fn prepend(self, elem: u32) -> List {
        // `Cons` also has type List
        Cons(elem, Box::new(self))
    }
"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.

"Consume" is entirely correct here. The thing you call prepend on is moved from and you can't use it again afterwards.

Karate Bastard
Jul 31, 2007

Soiled Meat
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?

Plorkyeran
Mar 22, 2007

To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed
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.

sarehu
Apr 20, 2007

(call/cc call/cc)
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.)

Vanadium
Jan 8, 2005

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.
You want to look at it from the outside for "consume" to make sense. From the example:
code:
    let mut list = List::new();

    list = list.prepend(1);
    list = list.prepend(2);
    list = list.prepend(3);
The notion that prepend consumes the receiver means that, for example,
code:
list.prepend(1);
list.prepend(2);
list.prepend(3);
would fail to compile because the first prepend call has consumed the list/moved the value out of the list variable, so the variable is consumed, moved-from, dead, until you put a new value in. I guess I'm not saying "consume" is the best word to use but it works for me here.

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!?
try! takes a Result<> and either evaluates to the value in the success variant, or it returns the value in the error variant from the function invoking try!, which it gets to do because it's a macro. So on error it returns early, and otherwise it continues in that it doesn't return early, and the code using try! can be written much as if it didn't have to deal with Result<>s as long as it returns the right kind of Result<> itself.

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.

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?
I have no idea who wrote the Rust by Example prose and I agree that a lot of the time the documentation is pretty poo poo and hard to understand if you don't already know what's going on, and I can only hope that it gets better now that it's not as much of a moving target. Sometimes the only way to really figure out what a language feature is about is to read the RFC where it was proposed and ideally the pull request where it was implemented, or just asking people on IRC because they're generally helpful (even if some of them are weirdos).

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.

Jabor
Jul 16, 2010

#1 Loser at SpaceChem

Vanadium posted:

I can't really argue with the rest of your points. But just to be clear...
try! takes a Result<> and either evaluates to the value in the success variant, or it returns the value in the error variant from the function invoking try!, which it gets to do because it's a macro. So on error it returns early, and otherwise it continues in that it doesn't return early, and the code using try! can be written much as if it didn't have to deal with Result<>s as long as it returns the right kind of Result<> itself.

Seems less useful than if Result<> just behaved like a proper monad IMO.

sarehu
Apr 20, 2007

(call/cc call/cc)

Jabor posted:

Seems less useful than if Result<> just behaved like a proper monad IMO.

It does.

Linear Zoetrope
Nov 28, 2011

A hero must cook
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.

Karate Bastard
Jul 31, 2007

Soiled Meat
Thanks for all the good points guys! I guess I'll find some toy problems to dick around with instead.

Vanadium
Jan 8, 2005

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

sarehu
Apr 20, 2007

(call/cc call/cc)
Have them draw lots, the loser gets hormone therapy.

Bognar
Aug 4, 2011

I am the queen of France
Hot Rope Guy

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

Bognar
Aug 4, 2011

I am the queen of France
Hot Rope Guy
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.

Subjunctive
Sep 12, 2006

✨sparkle and shine✨

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.

taqueso
Mar 8, 2004


:911:
:wookie: :thermidor: :wookie:
:dehumanize:

:pirate::hf::tinfoil:

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

Vanadium
Jan 8, 2005

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.

Workaday Wizard
Oct 23, 2009

by Pragmatica
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?

Subjunctive
Sep 12, 2006

✨sparkle and shine✨

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.

Redmark
Dec 11, 2012

This one's for you, Morph.
-Evo 2013

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

Workaday Wizard
Oct 23, 2009

by Pragmatica

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.

Adbot
ADBOT LOVES YOU

Vanadium
Jan 8, 2005

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.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply