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

Rust 1.26 released

blog.rust-lang.org

Post reply on HN
Print view View original

61–70 of 178 posts

Re: Rust 1.26 released

#61

Post by steveklabnik »

nikolay wrote: post #55
steveklabnik wrote: post #54

Earlier quoted context omitted.

They're very different languages, so different people like them for different reasons. Why is salt so popular today when pepper is just killing it?

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?

I don't think "systems programming" is a coherent concept anymore, so I'd reject the premise of the question. Go has already moved away from that word, Rust will be as well.

That you see them as being so different languages reinforces my premise above; they're good at different things, so comparing them doesn't always make a ton of sense.

Re: Rust 1.26 released

#62

Post by pcx »

saghm wrote: post #50
pcx wrote: post #45

The wonderful thing about Rust is that despite being fairly new and rare to get paid for working on it, it is still enticing( to most programmers I've met). The consistent effort to improve it is really paying off. I hope it gets to a place where it's `batteries included` like Python. There are some glaring holes in the stdlib I would like to see fixed sometime soon.

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…

That's certainly an advantage. But for devs like me, we are used to prog langs providing a set of APIs in the stdlibs, that are officially blessed to be maintained. They might not be the best designed, but they are guaranteed to work for a long long time. This kind of trust is very hard to build for 3rd part libs. It's a trade-off to make, and rust for now has decided to keep stdlib lean and quick to iterate over. But I hope at some point, Rust devs would consider including more APIs.

Re: Rust 1.26 released

#63

Post by cozicoolmail »

steveklabnik wrote: post #19
cjcole wrote: post #15

"Speaking of print, you can pre-order a dead tree version of the book from NoStarch Press. The contents are identical, but you get a nice physical book to put on a shelf, or a beautifully typeset PDF. Proceeds are going to charity." Which charity/charities?

Black Girls Code is the intention today, but originally it was going to be a different tech charity that is no longer around, OpenHatch.

Black Girls Code, in my opinion, is a great organization with a well executed mission and good reach (several major cities throughout the US). Glad Rust picked them.

Source: I've volunteered for them in the past as an instructor.

Re: Rust 1.26 released

#64

Post by all_blue_chucks »

pcx wrote: post #48
gamegoblin wrote: post #47

Earlier quoted context omitted.

Which glaring holes are there in your point of view? Rust devs are on HN a lot, so maybe they will see your comment. All that said, Rust definitely errs on the side of preferring to put things in 3rd party crates instead of stdlib, even for things that are very common to put in std for other languages (e.g. random number generation).

A couple of commong APIs I can think off the top of my head: - HTTP client - CSV parser/generator I know Hyper and rust-csv are popular. But having an stdlib that's much more feature complete would be great.

HTTP client: https://docs.rs/reqwest/0.8.5/reqwest/

Re: Rust 1.26 released

#65

Post by pjungwir »

Oh wow, this sounds great! I've hit both the long signatures when returning iterators, and also the dereferencing song-and-dance with match, and my Rust projects have been very limited. So I think these are huge improvements that will help a lot of other newbies like me. I can't wait to start using 1.26 instead. Thanks Rust team! :-)

Re: Rust 1.26 released

#66

Post by nostrademons »

nikolay wrote: post #52

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

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 graduated from college in 2005, and it was already 16 years old at the time.

Re: Rust 1.26 released

#67

Post by steveklabnik »

cozicoolmail wrote: post #63
steveklabnik wrote: post #19

Earlier quoted context omitted.

Black Girls Code is the intention today, but originally it was going to be a different tech charity that is no longer around, OpenHatch.

Black Girls Code, in my opinion, is a great organization with a well executed mission and good reach (several major cities throughout the US). Glad Rust picked them. Source: I've volunteered for them in the past as an instructor.

I have only heard wonderful things; I'm glad your experience is consistent :)

I have no idea how big the donations will be, but we're giving it a shot!

Re: Rust 1.26 released

#68

Post by saghm »

pcx wrote: post #62
saghm wrote: 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…

That's certainly an advantage. But for devs like me, we are used to prog langs providing a set of APIs in the stdlibs, that are officially blessed to be maintained. They might not be the best designed, but they are guaranteed to work for a long long time. This kind of trust is very hard to build for 3rd part libs. It's a trade-off to make, and rust for now has decided to keep stdlib lean and quick to iterate over. Bu…

I think that the rust-lang-nursery Github organization[1] is designed to solve part of the trust issue. A lot of the "batteries" crates are in there; `rand`, `futures`, `error-chain`, `lazy-static`, `glob`, `bitflags`, and `log` catch my eye after looking through. In the long run, I don't think that having things like the blessed HTTP library being third-party will be that much of a detriment; at least when I was writing Python, almost everyone I knew used the `requests` library, and nobody worried about it not being part of the standard library.
Post reply on HN