Results of Rust Survey 2016 – early draft for internal usage • Hacker News Board

Re: Results of Rust Survey 2016 – early draft for internal usage

#111

Post by mook » Sat, Jun 25, 2016, 3:22 PM UTC

Manishearth wrote: post #88

mook wrote: post #74

Earlier quoted context omitted.

Doesn't the large portion of people using unstable libraries / things depending on unstable internals mean that the versioning isn't covering a large enough API? I feel like blaming the user isn't really going to help make the ecosystem more stable. (Context: I went through the tutorial at one point and got really fed up that it wasn't possible to do it without involving crates because there wasn't any random number…

I wasn't talking about the stdlib, I was talking about crates. Rust tries to keep its stdlib small so that crates can evolve on their own (and have alternatives). I think that's a valid choice, just because needing to fetch a crate for random numbers is different doesn't necessarily mean it is bad. It also means that the versioning can be different -- the URL library can make breaking changes if it wants with a major…

Thanks for replying!

And my view is that having a smaller stdlib and pushing all the responsibility to crates means that the language isn't actually usefully stable, since it means downstream still can't depend on not having breaking changes of its dependencies. The URL library can make breaking changes and have a major version bump; but that means everybody ever that used a URL will need to deal with it, which can be annoying if you happen to be using a crate that does so half a dozen layers in. Saying that a library is broken because its dependencies changed shifts the blame but that doesn't actually help the end developer. I totally understand though; that's more of an artifact of having a young language. I just still find it frustrating.

As for unstable compiler plugins: sure, it's looking at dirty compiler internals and whatnot. But that means people are using non-release compilers, and makes it more likely to start using the same in their code. The same could have been achieved by having a compiler version (completely separate from the language version, sort of like how GCC version numbers are decoupled from the C language); instead, we've got instructions lying around encouraging people to use unreleased toolchains.

I guess I really just want a stable, battery-included thing to build on top of, but while Rust is exciting it isn't quite there yet. Really thankful for the Rust team (and friends) for working on all this and letting us have a look, though, and looking forward to the day the ecosystem gets there :)

Re: Results of Rust Survey 2016 – early draft for internal usage

#112

Post by mook » Sat, Jun 25, 2016, 3:27 PM UTC

dikaiosune wrote: post #86

mook wrote: post #74

Earlier quoted context omitted.

Doesn't the large portion of people using unstable libraries / things depending on unstable internals mean that the versioning isn't covering a large enough API? I feel like blaming the user isn't really going to help make the ecosystem more stable. (Context: I went through the tutorial at one point and got really fed up that it wasn't possible to do it without involving crates because there wasn't any random number…

I came from languages where a big standard library was de rigeur (python, java), and I quite like rust's approach personally. For one thing, having RNG in the standard library would make it much harder with rusts stability guarantee to iterate on the API design in meaningful ways. For another, it's way easier to maintain external dependencies in a rust project than in others. Cargo is like night and day compared to p…

Yes, it's harder to iterate on API design once it's in the stable API. But that's the point, basically; it's harder to keep code working if the thing you're using keeps iterating.

And yeah, cargo is really nice. I just think the part where you have to go to it for all the things, with no direction on which alternative is (API- / crash-) stable, maintained, etc. is frustrating. That's the thing a standard library gives me - curation.

Re: Results of Rust Survey 2016 – early draft for internal usage

#113

Post by scott_s » Thu, Jun 30, 2016, 8:20 PM UTC

alienated wrote: post #80

dochtman wrote: post #71

Earlier quoted context omitted.

I would argue that the language will benefit from having more diverse feedback.

Since you are prepared to make that argument, in what way will it benefit? Does the color of my skin, my gender or my sexual orientation matter when providing feedback for a project such as this? I would argue that those things are entirely irrelevant in this context, and wouldn't want them connected/associated with any contribution I made.

The general idea here is that when you are part of a majority, it's alarmingly easy to accidentally set up your community in such a way that makes those from a minority feel less welcome. It's a potential unknown-unknown. I assume the Rust community is trying to find out if this is the case.

Put another way, your skin color, sexual orientation, gender, etc. likely will not change your contribution. But if it turns out that people of a particular skin color, sexual orientation, gender, etc. are somehow disincentivized from contributing, that's a problem.