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

111–120 of 178 posts

Re: Rust 1.26 released

#111

Post by Sharlin »

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?

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.

Re: Rust 1.26 released

#112

Post by ovao »

nikolay wrote: 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 command line apps where you're just aborting whenever you hit any kind of snag, it's not a significant pain point.

Re: Rust 1.26 released

#113

Post by naasking »

burntsushi wrote: post #102
naasking wrote: post #84

Earlier quoted context omitted.

I think your explanation of static and dynamic dispatch is either wrong, or incredibly confusing. The offset of the function pointers is always statically known for a given trait/interface type, it's just the actual vtable instance that may not be known, ie. the concrete type implementing that trait/interface. A statically known vtable instance that can be inlined/monomorphized is static dispatch, and if it's not kno…

I don't understand what's so confusing about it. GP says "calling the trait method requires a dynamic lookup to find the method on the boxed object" It sounds like all you want to say is "calling the trait method requires a dynamic lookup to find [the vtable instance, which is then used to find] the method on the boxed object"

That's not the clarification I was making. For instance, I simply can't interpret this line from the original post as anything but incorrect:

> then the function pointer will always be in the same place on the object in memory (static dispatch)

As I said, static vs. dynamic dispatch is about knowledge of the vtable instance, not about the offset into the object or the vtable. All of the offsets are always known statically, it's merely what you're indexing into that may or may not be known statically.

Maybe I'm being pedantic, but I've found that there's a lot of misunderstanding surrounding static vs. dynamic dispatch.

Re: Rust 1.26 released

#114

Post by sriram_malhar »

nikolay wrote: post #52

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

I do a fair amount of Rust and Go, and I am not sure what axis you refer to with the phrase "killing". (Unless it is killing joy, for a lot of people )

Most apps out there are extremely serviceable with a language environment that runs up to 2x slower than what is possible with Rust. Youtube, edX, reddit, coursera all run on python, Facebook on PHP/Javascript, WhatsApp on Erlang.

In exchange for ceding low-level control, these languages provide a frictionless approach to evolving a system. You get dynamic features that are simply wonderful for creativity. Javascript is a blot on the landscape, but look at the effortlessness of d3.js.

GC is wonderful and does not gets in the way for most apps (from mobile to enterprise). Any time spent thinking about lifetimes sucks the fun out of coding. Lifetimes are fantastic for concurrent programming, no doubt, but there are simple patterns in Go that work well in practice.

Lightweight threads remove another point of friction; they allow you to model the concurrency inherent in a problem without much trouble. I'd prefer Go to get more of Erlang's failure handling and signal delivery mechanisms.

Go is a middling language, but its libraries and ecosystem are solid and have a coherent feel. They work out of the box without having to consult StackOverflow a zillion times.

The language I would love to have is Swift retrofitted with Erlang's process system.

Re: Rust 1.26 released

#115

Post by bvinc »

runevault wrote: post #13

Everyone keeps talking about impl Trait (which is great) but I'm super pumped for ? working in main now. Was recently writing some code as I finally got back to rust and forgot about that edge and had to write a match block when ? would have been good enough (felt silly to make a method just to handle that).

The first thing I always do is immediately make a function "main2" and make main an error handling function. It'll be nice to not have to do that.

Re: Rust 1.26 released

#116

Post by burntsushi »

naasking wrote: post #113
burntsushi wrote: post #102

Earlier quoted context omitted.

I don't understand what's so confusing about it. GP says "calling the trait method requires a dynamic lookup to find the method on the boxed object" It sounds like all you want to say is "calling the trait method requires a dynamic lookup to find [the vtable instance, which is then used to find] the method on the boxed object"

That's not the clarification I was making. For instance, I simply can't interpret this line from the original post as anything but incorrect: > then the function pointer will always be in the same place on the object in memory (static dispatch) As I said, static vs. dynamic dispatch is about knowledge of the vtable instance, not about the offset into the object or the vtable. All of the offsets are always known stati…

I see. Makes sense. It might help to show what the representation in memory of a trait object is. (I'm assuming there's a type for it somewhere in rustc, but I don't know where offhand.)

Re: Rust 1.26 released

#117

Post by steveklabnik »

burntsushi wrote: post #116
naasking wrote: post #113

Earlier quoted context omitted.

That's not the clarification I was making. For instance, I simply can't interpret this line from the original post as anything but incorrect: > then the function pointer will always be in the same place on the object in memory (static dispatch) As I said, static vs. dynamic dispatch is about knowledge of the vtable instance, not about the offset into the object or the vtable. All of the offsets are always known stati…

I see. Makes sense. It might help to show what the representation in memory of a trait object is. (I'm assuming there's a type for it somewhere in rustc, but I don't know where offhand.)

https://doc.rust-lang.org/stable/std/raw/struct.TraitObject....

Re: Rust 1.26 released

#118

Post by oblio »

staticassertion wrote: post #86
oblio wrote: 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…

You misread what I said. Click my link and tell me what you see. Hint: there’s a reason those things are called “suggested extensions”.

Re: Rust 1.26 released

#119

Post by kccqzy »

Existential types are great! Although I must mention that existential types are basically the way to model OO-style information hiding. It's a great tool to have in any mature type system, although I do wonder how it is compiled. Trait objects are kind of easy to imagine: a heap-allocated dictionary of methods for that trait. I do wonder how heap allocation is being avoided in this case.

EDIT: I didn't read closely enough. Only a single type is allowed, so the traditional existential type construct ("trait objects") are still needed.

Re: Rust 1.26 released

#120

Post by kibwen »

kccqzy wrote: post #119

Existential types are great! Although I must mention that existential types are basically the way to model OO-style information hiding. It's a great tool to have in any mature type system, although I do wonder how it is compiled. Trait objects are kind of easy to imagine: a heap-allocated dictionary of methods for that trait. I do wonder how heap allocation is being avoided in this case. EDIT: I didn't read closely e…

There's intentionally no heap allocation or virtual dispatch when using `impl Trait`; if we were content with that, we wouldn't have bothered implementing it and just continued on as we were with `Box`. :P
Post reply on HN