Live data from Hacker News

Rust 1.26 released

blog.rust-lang.org

141–150 of 178 posts

Re: Rust 1.26 released

#141

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.

what else would you say it is missing?

Unfortunately I don't have a good full response to this (otherwise I could contribute it and actually help), but off-head I was surprised by the lack of a `cargo install` (https://github.com/rust-lang/cargo/issues/2179). A few minutes later though I was used to googling for the package i wanted, and getting the version I wanted to use and adding it to Cargo.toml, and that's arguably a better way to do things to start with.

I haven't used it enough to have much more to say -- I've found everything pretty ergonomic so far (especially for a C/C++-tier language), I was most frequently confused when thinking of the most idiomatic way of doing something, but that's remedied by reading more (the rust book first/second edition, the rust cookbook). This should change over the coming weeks.

This isn't a particularly useful comment, but I chose Rust over Common Lisp recently for this new project, and I've found the std library's google-ability to be excellent for rust -- very few pages about steel have come up so far ("result rust" in DDG brings up rustlang related links). When I explored CL, I did not find that to be the case, but maybe I just didn't know where to look -- hyperspec is close but it is a terrible document to navigate through, and the 90s graphics didn't help (though they were nostalgic). Rust documentation is very often concise, well structured, and passably beautiful. I was also pleased with the Abstract Data Type solution in rust -- tagged unions. Some code:

    #[derive(Debug)]
    pub enum ConfigLoadError {
        EmptyFilePath,
        IO(IOError),
        TomlParse(TomlError)
    }
The abstraction enabled here is just right for me, super similar to code that I'd write in Haskell, and helps me abstract over errors thrown by utility libraries (in this case `toml-rs`).

Re: Rust 1.26 released

#142
post #126

Earlier quoted context omitted.

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.

> i can with zero effort and 100% confidence run any old Go code i have lying around. that's pretty awesome. I think you can do that in Rust too (post 1.0). What's more impressive is that canonical go code from five years ago is still canonical.

whether that's impressive or not is very much a matter of perspective -- it is certainly remarkable! :-)

Re: Rust 1.26 released

#143

Earlier quoted context omitted.

what else would you say it is missing?

Unfortunately I don't have a good full response to this (otherwise I could contribute it and actually help), but off-head I was surprised by the lack of a `cargo install` ( https://github.com/rust-lang/cargo/issues/2179 ). A few minutes later though I was used to googling for the package i wanted, and getting the version I wanted to use and adding it to Cargo.toml, and that's arguably a better way to do things to sta…

You may want to see the failure crate. In my practice most errors cannot be handled by a program and the only sensible thing to do is to pass an error description to a user or a programmer. Such fine-grained error type information as in your example is rarely useful. The failure crate provides a way to create detailed error descriptions (see `Context`) and fixes shortcomings of the standard Error trait.

Re: Rust 1.26 released

#144
post #95
post #89

Earlier quoted context omitted.

You're the one that said "Google is emotionally attached to Golang, which was born at Google." which is really stupid tbh you think engineers at Google pick up tech because they're "emotionally attached"? Those smart people took the tool that fits their needs.

I'm sorry, but Google isn't some role model with high values. On the contrary, it makes most of its money from selling our dirty underwear to merchants.

It also spends money developing genuinely unencumbered programming languages that are, in general fact, quite pleasant.

Google can make money in one way and still provide real value in others, and that’s what they (and all of Go’s contributors) have done with Golang.

Re: Rust 1.26 released

#145
post #62
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…

What sort of maintenance is actually needed though?

Rust promises that existing versions of crates will build and run in the future, assuming the crate is well-behaved and doesn't do anything illegal with unsafe code. That's part of Rust's general stability guarantee.

Maybe "blessed to be maintained" means crates get ongoing critical security fixes? Thanks to Rust, for most crates that's a very low-probability concern. (Obvious exceptions for features like HTTP and TLS that contain their own security decisions.)

Maybe you mean that all kinds of bugs will continue to be fixed and the quality of the crate will keep increasing? I don't think any languages really give you that; they all have standard library features that are effectively end-of-life. A lot of application developers don't even WANT such fixes since there's always a risk of breaking previously-working applications.

So I think it would make sense for the Rust community to commit to a subset of crates for ongoing maintenance, but for probably the majority of crates you could just keep using the exact same version for the next five years with no worries.

Re: Rust 1.26 released

#146
post #112
post #52

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

If the Rust ecosystem was up to snuff on the HTTP front, I'd be writing a lot more of it. At the moment, Go's HTTP implementation is just pretty much unbeatable. I'm confident it'll get there — and there's a ton of great work going on to get it there — but at the moment, it's still the Wild West. Go also hits the sweet spot for CLI apps, in my opinion. The error handling is obtrusive and annoying otherwise, but for c…

"up to snuff on the HTTP front"

I think this is a pretty major piece as well. Go was introduced many years earlier, backed by Google marketing and had strong HTTP services as a day one feature; it was designed for probably the most popular use case by perhaps the most influential fount of new tech. Given all that has Go really done all that well? Has it gone much beyond network services and a couple other niches (Docker/K8s etc?) It's not really displacing C/C++ in 'systems' use cases. It's not a go-to language for Machine Learning. The runtime+GC obviates most embedded work. You don't see any meaningful uptake of Go among Google's peers; Apple, Microsoft, Oracle, etc. I wonder just how important Go really is.

Re: Rust 1.26 released

#147
post #48

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.

These are really interesting examples. In Python, the HTTP client in the standard lib is pretty crappy compared to requests, which is the defacto standard. Likewise, the CSV library in the Python stdlib is not very good, but can't improve much for compatibility reasons.

Developers have different needs. Some value stability, some value bleeding edge features. Trying to put libraries in the standard library and freezing their interface is really tricky to balance.

Though the ecosystem is still young, the long term story for "batteries included" in Rust is going to be a rich ecosystem in Cargo, not a rich standard library.

Re: Rust 1.26 released

#148
post #52

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

Letting GC take care of lifetimes is a big plus for many applications. Rust's ownership model buys you a lot --- no GC overhead (space, not just time), fearless parallelism, more powerful static invariants --- but it costs you development effort, and depending on your application the costs can outweigh the benefits.

Rust improvements like NLL will hopefully reduce the costs. I think we will discover more ways to leverage the benefits, over time. However, I also think it might be interesting to let people opt into a Rust dialect that hides lifetime issues, e.g. using a lot of implicit Rcs and (Ref)Cells.

Re: Rust 1.26 released

#149
post #72
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?

gVisor is a security product ( Container Runtime Sandbox ) made by Google in Go and runs in production so I'm not sure what you mean by "how vitally important security is in that domain". https://github.com/google/gvisor

gVisor is not a good poster child for Go. It hacks generics into Go via a preprocessor!

Re: Rust 1.26 released

#150
post #127

Earlier quoted context omitted.

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.

Perhaps one could say that about systems programming languages as well, including Rust. It'll be slow(er) to develop, and there will be much wailing and gnashing of teeth.

The word "systems" is increasingly relegated to a smaller fraction of the codespace than used to be; one wouldn't have considered building a high frequency trading system or a call handling system in a non C/C++ language in the mid 90's, but Java and Erlang get the job done well enough.

As always Alan Perlis said it best (in his "epigrams of programming"): A programming language is low level when its programs require attention to the irrelevant!

Post reply on HN