Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Results of Rust Survey 2016 – early draft for internal usage

docs.google.com

Post reply on HN
Print view View original

81–90 of 113 posts

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

#81

Post by vfclists »

EugeneOZ wrote: post #53
viraptor wrote: post #48

Earlier quoted context omitted.

I'd also like to see that. I'm in the "temporarily stopped using" camp. I love it, I got to the level where I don't fight the language anymore, but facing reality - I don't have a reason to use it. Everything I do at the moment, I can finish faster in Python and I know it's enough. (sysadmin / deployment / security tools) The moment I need good performance and safety (new protocol server?), I'll reach for Rust. But I…

I went further and now I write in Rust with the same speed as with PHP. And my benefits: awesome system of errors handling, enums, match patterns, easy and safe multithreading, MySQL shared prepared queries, and majority of bugs is being catched by compiler (thanks to strict typing and a lot of checks in compiler).

being caught by the compiler.

Have you been writing too many try/catch statements?

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

#82

Post by steveklabnik »

mook wrote: post #74
Manishearth wrote: post #34

Earlier quoted context omitted.

I believe (but cannot verify) that these breakages were due to libraries breaking, especially libraries which evolve in lockstep with Rust internals like aster. The main reason I believe this is because each release is tested against the entire ecosystem, and stability regressions are fixed. The only time that breakages in the ecosystem are okay are during a soundness fix where the broken library was doing something…

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…

  > isn't covering a large enough API?
We stabilize lots of stuff every release, but we also don't want to stabilize things that aren't ready. Once we do, we're stuck with that interface forever.

A significant portion of nightly users are on it due to compiler plugins, even for libraries that work on stable, because it makes development a bit easier. Stabilizing those immediately would mean stabilizing compiler internals, which is a pretty huge drawback.

We have plans for addressing that specifically, as well as for the more general "libraries change" problems. They will come as part of an actual announcement, not a leaked first draft blog post :)

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

#83

Post by eximius »

adrusi wrote: post #79
dochtman wrote: post #71

Earlier quoted context omitted.

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

Does anybody actually believe that diverse cultural backgrounds are at all relevant to ideas about programming language design or compiler programming? Claims that diversity is good for project organization sound believable, but I see no reason to think the diversity of background has any impact on technical contributions. There is no moral obligation to have a diverse group, just to have a group that is tolerant of…

Thank you for coherently and politely saying what others have said in... less eloquent terms. I think many people feel this way but find it difficult to express in these contexts without coming off as (or at least being accused of) a bigot or something.

My post above was a super-passive expression of this.

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

#84

Post by steveklabnik »

panic wrote: post #32
jjnoakes wrote: post #30

Earlier quoted context omitted.

I don't know the details in rust's case, but I wouldn't consider it a violation of semver if the code which broke in a minor update was doing bad things (maybe accidentally exploiting a bug or limitation in the language or implementation, probably by violating some requirement that wasn't checked properly, etc) and simply couldn't be correct code if left alone.

How do you define a "bad thing"? The semver spec is quite clear about "even the tiniest backwards incompatible changes" ( http://semver.org/#if-even-the-tiniest-backwards-incompatibl... ) requiring a major version bump.

Semver does not define what a "compatible" vs "incompatible" change means, though. Manish linked to how we define it, but SemVer specifically leaves that up to the project.

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

#85

Post by kbenson »

alienated wrote: post #73
Manishearth wrote: post #42

Earlier quoted context omitted.

I know. I'm not questioning the intention, I'm requesting the term not be used that way -- it is known to alienate people.

> it is known to alienate people. So is language policing. The Rust Code of Conduct [0] states: Don’t just aim to be technically unimpeachable, try to be your best self. In particular, avoid flirting with offensive or sensitive issues, particularly if they’re off-topic; this all too often leads to unnecessary fights, hurt feelings, and damaged trust; worse, it can drive people away from the community entirely. You've…

You know, if you feel the need to make an account to post what amounts to a rules lawyering comment to what you perceive as a language police comment, perhaps you're taking the wrong approach. There are less blunt methods.

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

#86

Post by dikaiosune »

mook wrote: post #74
Manishearth wrote: post #34

Earlier quoted context omitted.

I believe (but cannot verify) that these breakages were due to libraries breaking, especially libraries which evolve in lockstep with Rust internals like aster. The main reason I believe this is because each release is tested against the entire ecosystem, and stability regressions are fixed. The only time that breakages in the ecosystem are okay are during a soundness fix where the broken library was doing something…

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 pip, for example.

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

#87

Post by alienated »

kbenson wrote: post #85
alienated wrote: post #73

Earlier quoted context omitted.

> it is known to alienate people. So is language policing. The Rust Code of Conduct [0] states: Don’t just aim to be technically unimpeachable, try to be your best self. In particular, avoid flirting with offensive or sensitive issues, particularly if they’re off-topic; this all too often leads to unnecessary fights, hurt feelings, and damaged trust; worse, it can drive people away from the community entirely. You've…

You know, if you feel the need to make an account to post what amounts to a rules lawyering comment to what you perceive as a language police comment, perhaps you're taking the wrong approach. There are less blunt methods.

You are right, and I apologize.

It was done to belabor a point. Namely that for a community that aims to be welcoming, belaboring that point can actually make it less welcoming.

It is taxing to participate in an environment where common language usage causes people to take offense where none is given or intended.

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

#88

Post by Manishearth »

mook wrote: post #74
Manishearth wrote: post #34

Earlier quoted context omitted.

I believe (but cannot verify) that these breakages were due to libraries breaking, especially libraries which evolve in lockstep with Rust internals like aster. The main reason I believe this is because each release is tested against the entire ecosystem, and stability regressions are fixed. The only time that breakages in the ecosystem are okay are during a soundness fix where the broken library was doing something…

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 version bump, and that's okay.

Sometimes, a breaking change in the ecosystem is marked as a minor version bump, and sometimes you need to coordinate versioning across crates. This causes breaking changes for downstream users.

------

Most of the actual libs with unstable rust dependencies out there are compiler plugins. "Things depending on unstable internals" exist in many communities and Rust is no different. That doesn't necessarily mean these internals should be stabilized.

A big one is clippy, which I maintain. This lints code by hooking directly into compiler APIs, which will never be stable to the extent clippy needs them to be, since that would freeze compiler evolution. Similar tools for other languages either reimplement a mini-parser+typechecker internally, or hook directly into the compiler (gimple passes, etc). There is a solution being worked on for clippy specifically. For tooling/IDEs in general, the Rust compiler will eventually get an "oracle" API that can be queried for type information and whatnot (which probably won't have enough info for clippy to work, but will have enough for general IDE stuff)

Another big one is serde, the community serialization library. There is an official one that works pretty well, but serde is better. However, the serialization codegen is done by a plugin. It can also be done with a build script on stable, but this is a bit more unwieldy. Some libraries use the plugin instead of the build script, and often break.

There is work going on for a better procedural macro/metaprogramming interface too.

That is mostly the extent of things which depend on Rust unstable internals and are used widely. There are a few more things, but they are less used.

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

#89

Post by badsock »

itxifxuf wrote: post #15
Perceptes wrote: post #14

Earlier quoted context omitted.

Programming languages are used for and by humans. The experience of the people using the language plays a massive role in the success of the language and of the software built with it.

So why are we needlessly injecting race and sexual orientation into something that used to be just about programming? Are we tracking the demographics for lawn sprinkler users with equally bated breath? Stop trying to insert your identity politics into everything. Let's just leave a few pure things in this world, please.

What I don't get is how you consider this such an important crusade to go on. Is collecting the opinions of under-represented groups such an objectively damaging thing that you're going to spent your limited energy and time on earth fighting that? Can you seriously think of no better things to be concerned about?

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

#90

Post by carols10cents »

alienated wrote: post #87
kbenson wrote: post #85

Earlier quoted context omitted.

You know, if you feel the need to make an account to post what amounts to a rules lawyering comment to what you perceive as a language police comment, perhaps you're taking the wrong approach. There are less blunt methods.

You are right, and I apologize. It was done to belabor a point. Namely that for a community that aims to be welcoming, belaboring that point can actually make it less welcoming. It is taxing to participate in an environment where common language usage causes people to take offense where none is given or intended.

Using the word "guys" to describe Rust developers is not offensive; it's just incorrect.
Post reply on HN