Live data from Hacker News

Rust 1.26 released

blog.rust-lang.org

121–130 of 178 posts

Re: Rust 1.26 released

#121
post #56

Earlier quoted context omitted.

Maybe after the community chooses a few “winners” the Rust devs could promote them as being “suggested” packages? Also, some suggested metapackages/bundles wouldn’t hurt for newbies, like a set of crates for developing command line tools, for example. Something like this: https://marketplace.visualstudio.com/

Why choose a winner? What if a 'winner' today is a loser in a year? What if we come up with a new approach to solving a problem that requires a breaking change, or a new crate? Would someone be inclined to try to improve the state of HTTP given a good enough version in std? Would we be ok with discouraging that sort of competitive approach? To be honest, all I see are downsides to having a huge std lib. The benefit s…

Perhaps a better idea might be to include the most popular client in some form of official tutorial / guide / documentation, or as part of some extended documentation separate to the language doc?

That way libraries can coexist, but new developers have a single doc location to go to to find really common usages.

Re: Rust 1.26 released

#122
post #92
post #50

Earlier quoted context omitted.

The argument for putting things in third-party "blessed" crates rather than the standard library is that it allows them not to have to follow the versioning guarantees of Rust itself. Given that the core team has stated that they don't plan to have a Rust 2.0, this means that there wouldn't _ever_ be any API-breaking changes for things added to the standard library; by having things like `regex` and `rand` be externa…

But the versioning guarantees are _exactly_ why having them in the stdlib would be good for me as a user; it means I'd be able to have code that keeps working, but have new improvements available. It's totally fine to decide to make the trade off, but it's just frustrating to not have the downside acknowledged.

Yeah, but 20 years down the road, you're either going to be writing the same code or sifting through piles of crufty bad stuff.

Re: Rust 1.26 released

#123
post #52

I really wonder why is Golang so popular today when Rust is just killing it?

Aside from the head start, I believe Go legitimately hits a sweet spot for developers wanting a language that's relatively easy to use yet also fast and fully compiled. Rust on the other hand is targeted more towards developers that want C-like low-level control along with safety against shooting themselves in the foot. The former audience is probably larger than the latter. But popularity isn't everything (JavaScrip…

Personally... I used to write Java and Python code (and enjoy it), but fairly straight forward code would just bog down on me. On the other hand, C and C++ code would always crash in frustrating ways.

Rust hits the sweet spot of not being a pain in my ass all the time.

Re: Rust 1.26 released

#124

Earlier quoted context omitted.

Why choose a winner? What if a 'winner' today is a loser in a year? What if we come up with a new approach to solving a problem that requires a breaking change, or a new crate? Would someone be inclined to try to improve the state of HTTP given a good enough version in std? Would we be ok with discouraging that sort of competitive approach? To be honest, all I see are downsides to having a huge std lib. The benefit s…

Perhaps a better idea might be to include the most popular client in some form of official tutorial / guide / documentation, or as part of some extended documentation separate to the language doc? That way libraries can coexist, but new developers have a single doc location to go to to find really common usages.

This is a strategy we’re pursuing but haven’t shipped yet https://github.com/rust-lang-nursery/rust-cookbook

Re: Rust 1.26 released

#126
post #80

Earlier quoted context omitted.

Also Go's 1.0 predated Rust by about 5 years. They started around the same time, but many people won't use a language that's not stable where their existing code may break with each new release. Go has had a ~5 year head start in developing a library ecosystem, tooling, commercial users, etc. It takes a long time for a language to build momentum and a user base. Python was just starting to get popular when I graduate…

This is true, but even today in 2018, Golang still suffers from the dependency-management hell, the notorious GOPATH, and many other issues it should not have being almost a decade old! Even Rust, which some call "lower-level language", which it is not, has Cargo after it learned from Ruby and Node how important is to have easy package management, and being able to install a new project without knowing almost anythin…

totally fair, but Go did stablize the language itself. i can with zero effort and 100% confidence run any old Go code i have lying around. that's pretty awesome.

Re: Rust 1.26 released

#127
post #55

Earlier quoted context omitted.

Well, every two languages are different, but at least for systems programming, Golang unfortunately started to replace Python, but given how vitally important security is in that domain, Rust makes a lot more sense than Golang, won't you agree?

Once you start putting "systems programming" and "Python" in the same sentence you can be pretty sure that the term "systems programming" has lost all meaning. Or at least using it without elaborating is only going to end up in confusion.

Python is for systems programming like your fist is for hammering nails -- it will be slow, and there will be blood.

Re: Rust 1.26 released

#128

So, so, so much stuff in this release! The next few are shaping up to be similar. Very exciting times! As always, happy to answer questions, provide context, etc.

With the release of impl Trait (easily the feature I've been most looking forward to), has there been any talk of/proposals to allow anonymous trait implementations? (see: https://github.com/rust-lang/rfcs/pull/2406#issuecomment-384... for an example of what it might look like)

Being able to return anonymous trait impls from inside functions could eliminate a lot of what seems like boilerplate structs/impls from Rust code. As an example, the code in futures-util that adds combinators to a Future defines a type (Then, Fuse, Map, etc) for each combinator function. With those functions now able to use 'impl Future' as the return type, being able to actually type 'return impl Future' could make code like that a lot less cluttered.

Re: Rust 1.26 released

#129
As a person who started writing rust this last week, I think I might have picked the best possible time to get in on it.

The community is amazing, and I actually understand all these features that were released I've run into about half of the issues they fix already.

Rust is coming along very very nicely.

Re: Rust 1.26 released

#130

So, so, so much stuff in this release! The next few are shaping up to be similar. Very exciting times! As always, happy to answer questions, provide context, etc.

With the release of impl Trait (easily the feature I've been most looking forward to), has there been any talk of/proposals to allow anonymous trait implementations? (see: https://github.com/rust-lang/rfcs/pull/2406#issuecomment-384... for an example of what it might look like) Being able to return anonymous trait impls from inside functions could eliminate a lot of what seems like boilerplate structs/impls from Rust…

I’m not aware of any real proposal.
Post reply on HN