Live data from Hacker News

Rust 1.26 released

blog.rust-lang.org

151–160 of 178 posts

Re: Rust 1.26 released

#153
post #151

Earlier quoted context omitted.

But it wouldn’t require a heap allocation.

Where is the proxy implementation going to go if not the heap?

The proxy object would have statically known size (maximum of the size of the types it dispatches between, plus some metadata such as a vtable pointer or an enum discriminant). Now, because you know the size statically, you can store it in the stack.

Re: Rust 1.26 released

#154
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…

Hyper 0.12 is right around the corner with the excellent h2 crate. We've been using the master branch on production the whole 2018 and it's super fast, stable and ergonomic.

Re: Rust 1.26 released

#155
post #24

> Inclusive ranges are especially useful if you want to iterate over every possible value in a range Out of curiosity, why was the (or an alternative) choice not to make the compiler understand that the 0..256 was not inclusive, and somehow correct the literal value to do what's intended? Would that have been unusually complicated or? Edit: Overall, still an amazing release, this was just the bit I'm curious about :)…

There is actually a simple reason for that: the ranges might not be constant literals. So the end value must be an expression of some type; here u8. u8 can hold only values 0-255; 256 is out if its range.

Re: Rust 1.26 released

#156
I wrote a program yesterday in 1.25 which did some simple file I/O right there in main, didn't need to be fancy at all... and then this morning I come online and find that we now have fs::read_to_string and main can return a Result... great!

But I needed this yesterday!

Seriously though, this is an amazing release and so much stuff in here I've been looking forward to for ages. impl Trait is going to change the way I write Rust.

Re: Rust 1.26 released

#157
post #149
post #72

Earlier quoted context omitted.

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!

I'd say on the contrary. They chose it even while knowing they'll gonna need to hack generics. (Same in k8s, generics hacked together in a few different ways)

Re: Rust 1.26 released

#158
post #112

Earlier quoted context omitted.

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 (Doc…

Actually, as far as I know, Microsoft is using Go in a few places in Azure.

Re: Rust 1.26 released

#159
post #112

Earlier quoted context omitted.

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 (Doc…

> Given all that has Go really done all that well?

My intuition is that the only languages that have grown faster are those that were blessed as "native" for a popular platform. For it's age it seems to be doing really really well.

But given Go's mix of advantages and disadvantages, should we expect it to be doing better? I doubt it.

Still to be seen if it becomes a Ruby or a Java, though.

Re: Rust 1.26 released

#160
post #149

Earlier quoted context omitted.

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

I'd say on the contrary. They chose it even while knowing they'll gonna need to hack generics. (Same in k8s, generics hacked together in a few different ways)

You're starting from the assumption that the Google developers took a clear-eyed decision on the merits, which I don't share.
Post reply on HN